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

From: "Dean Willis" <[email-masked]>
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 4 Dec 2002 19:42:49 -0600

By the way, 3GPP proxies are much more conformant now than they were
when I first posted this, so please don't beat them up about anything
here. They've done a great job improving the transparency of their
system. Thank you, 3GPP!

--
Dean

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Wednesday, December 04, 2002 7:23 PM
> To: [email-masked]
> Subject: [Sip] Back-to-Back User Agent Ttransparency Top 10 list
> 
> 
> 
> 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.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
>