Re: [Sip] Back-to-Back User Agent Ttransparency Top 10 list

"4) Header transparency: The B2BUA doesn't change headers that transit it."

This mail seems to suggest that a B2BUA forwards the headers to the other endpoint (in other words does not change the headers that transit it) .

Am I wrong in this assumption?

The content of this mail would definitely be pretty useful in a draft on the B2BUA.

Regards

Padma

>From: "Dean Willis"

>To:

>Subject: [Sip] Back-to-Back User Agent Ttransparency Top 10 list

>Date: Wed, 4 Dec 2002 19:23:23 -0600

>Apologies to those of you who have seen this before. It's a couple of

>years old, which explains my frustration with this particular topic.

>Note that "conformant" proxies satisfy all 10. Strict UAs satisfy none.

>----------------------------

>1) Dialog transparency: The call-ID is the same on "both sides" of the

>B2BUA. Proxies have this characteristic. A B2BUA that actually

>terminates a dialog on one side and generates a new dialog on the other

>doesn't. Some 3GPP AS functions fall into this category, as do 3PCC

>controllers.

>2) Identity transparency: The user appears to have the same identity on

>both sides of the B2BUA. A proxy has this property. An identity

>anonymizer doesn't.

>3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A

>traditional proxy has this property. A 3GPP P-CSCF does not, as it can

>generate a BYE message and then have to manage disjoint CSEQ spaces on

>each side.

>4) Header transparency: The B2BUA doesn't change headers that transit

>it. Proxies have mostly this property, changing onlya few headers that

>are specifically changed by the proxy function. Proxies don't change

>headers they don't understand. 3GPP "proxies" are likely to go to town

>changing all SORTS of headers. All with the best of intentions, mind

>you.

>5) Body transparency: The MIME bodies on the SIP message are not

>altered by the B2BUA. Real SIP proxies have this property. Firewall

>proxies that modify SDP, and most everything in 3GPP, doesn't.

>6) Media transparency: AS with body transparency, but considering only

>the media aspects. The 3GPP P-CSCF breaks this transparency rule by

>editing one's SDP to meet operator preferences.

>7) Topology transparency. Via, Route, Record-Route, Path,

>P-Service-Route, and other headers that reveal topology are roughly the

>same on both sides of the B2BUA, save for any which uniquely identify

>that B2BUA. Proxies have this characteristic. Topology hiding devices

>like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP

>THIG don't.

>8) Security transparency: The B2BUA doesn't alter security aspects,

>such as encryptions, authorization headers, etc. Proxies generally have

>this property, but 3GPP stuff doesn't.

>9) Accounting transparency: Stuff used to generate records or track

>usage is not altered by a B2BUA with this property. Proxies have this

>property. 3GPP is trying to define a P-header (P-original-dialog-ID, I

>believe) to provide for accounting transparency across 3GPP AS elements

>operating at a low level of transparency.

>10) Functional transparency: The task that the user of the UA wants to

>accomplish actually works across the B2BUA, rather than being

>blocked/distorted by it. Proxies generally have this property, with the

>caveat the proxy can reject a request if needed. Some 3GPP entities can

>mutate functionality beyond all recognition. This is probably the

>single most important transparency concept. The rules of a "proxy" as

>defined in RFC3162 are there to preserve functional transparency, and

>anything that "breaks" those rules is likely to compromise

>functionality in some way.

>_______________________________________________

>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip

>This list is for NEW development of the core SIP Protocol

>Use sip-implementors@cs.columbia.edu for questions on current sip

>Use sipping@ietf.org for new developments on the application of sip