Re: [dispatch] B2BUA-taxonomy for STRAW WG

[Dean Willis <[e-mail]>]

On Sat, Oct 15, 2011 at 12:31 AM, Hadriel Kaplan <[e-mail]> wrote:
>
> As part of the proposed STRAW WG charter, a possible deliverable might be a taxonomy document of B2BUA roles as might be useful for STRAW WG work items to reference.
>

Howdy, Forks!

I believe I enumerated some aspects of transparency on one of our
lists back in 2002 that might be relevant to this discussion:


Repost follows:
-----------------------


The 3GPP idea is to try and make the B2BUA as "transparent" to new
functions as it can be while still accomplishing other things required
by 3GPP. I suspect they're a long way from solving this, as it makes for
wicked and subtle compromises.

One might argue that a proxy is, by definition, a particularly
transparent B2BUA -- it basically alters nothing but the next hop, and
doesn't mess with things it doesn't understand.

One can actually define a whole range of "transparency" if one is so
inclined. I suppose I should write a draft on this someday. But it makes
a good Top-10 list . . .

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.



-- 
Dean Willis