Subject: [Sipping] Transparent B2BUA?

From: 莊力中(ljchuang) <[email-masked]>
Date: Mon, 13 May 2002 14:46:34 +0800

Hi, forks:

I've learned that a 3GPP CSCF is a transparent B2BUA, just wondering what
the "transparent" means,.
What is the difference between a transparent B2BUA and a non-transparent
B2BUA? could someone 
answer this question? Any help is highly appreciated!

---

From: Chris Martin <[email-masked]>
Date: Mon, 13 May 2002 08:24:45 -0500

> ²ø¤O¤¤(ljchuang) wrote:
> 
> Hi, forks:
> 
> I've learned that a 3GPP CSCF is a transparent B2BUA, just wondering
> what the "transparent" means,.
> What is the difference between a transparent B2BUA and a
> non-transparent B2BUA? could someone

I would assume that it means that the client doesnt have to point to it
aas an outbound proxy, (meaning it is possibly inline with the data
path)

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 May 2002 15:29:39 -0400

> aas an outbound proxy, (meaning it is possibly inline with the data

I don't think so. The client does explicitly point to the P-CSCF as its
outbound proxy. I assume "transparent" is meant to imply that it doesn't
do things like stripping of headers or bodies, so that (hopefully) new
features will work through it as if it were in fact a proxy. THis is
just a guess though.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 13 May 2002 21:05:07 -0700

Hmm, I have always wondered what a transparent B2BUA was myself. I really
don't know but I had assumed that it was a B2BUA where if it received a
transaction on the left hand side, it tried to do a very similar (but
different) transaction on the right hand side. It may not fully understand
what this transaction means - perhaps it passes headers it does not
understand from one side to the other - it could even pass messages types it
did not understand.

It's a good question - other possibilities of what a "transparent" B2BUA is?
I hope the answer is not "a proxy that does things that a proxy is not
allowed to do".

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Chris Martin
> Sent: Monday, May 13, 2002 6:25 AM
> To: ²ø¤O¤¤ (ljchuang)
> Cc: [email-masked]'
> Subject: Re: [Sipping] Transparent B2BUA?
>
>
> > ²ø¤O¤¤(ljchuang) wrote:
> >
> > Hi, forks:
> >

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 May 2002 01:10:08 -0500

> > Hi, forks:

I don't know if the above was a typo, but if not, I think it's a GREAT
SIP pun describing people who deal with too many forking proxies . . .
(yes, I did promise not to seriously call for the dprecation of forking
anymore, but this is FUNNY)

> aas an outbound proxy, (meaning it is possibly inline with the data

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

---

From: Michael Hammer <[email-masked]>
Date: Tue, 14 May 2002 17:25:51 -0400

Dean,

You say what it doesn't do different from a proxy, what is different?

Is it allowed to send BYE to terminate a call when pre-paid or extension of 
credit dries up?

Mike

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 May 2002 19:55:22 -0500

Several of the elements of the 3GPP architecture appear to "break the
rules" of being a proxy and display other behavior on the B2BUA
continuum. This would appear to reduce transparency relative to a pure
proxy.

These include:

1) The P-CSCF may send a BYE on behalf of the UA, generally because the
P-CSCF has been notified by the radio layer that the UA has lost
contact.  Of course, it doesn't have the credentials to authenticate the
BYE, so many UAs will consider this as a forged message.

2) The P-CSCF strips away Route, Record-Route, Via, Path, and
P-Service-Route headers before passing messages on to the UA. It then
reinserts them properly on messages in the other direction, and may also
strip out Route headers inserted by the UA.

3) The P-CSCF may edit SDP sent from or to the UA in order to force the
selection of codecs considered favorable to the operator. Yes, they
think they're billing for bits on a per-minute basis . . . We're
negotiating this one, as Rosenberg has proposed a new mechanism by which
a proxy may request SDP grooming from a UA.

4) The P-CSCF MAY (this is being fought now) obfuscate the To: and From:
fields in messages.

5) The P-CSCF filters messages from the UA to assure that only an
identity known to the P-CSCF is presented by the UA. This may interact
with the preceding characteristic. This appears to be required to
accomodate the authorization model of 3GPP, which authenticates only
REGISTER transactions and uses them to establish a security association
between UA and P-CSCF.

5) The S-CSCF (or an application server, which may be colocated with the
S-CSCF) may send a BYE both to and on behalf of of subscriber if the
account runs out of money or is otherwise deactivated.  Of course, it
doesn't have the credentials to authenticate the BYE, so many UAs will
consider this as a forged message.

6) The I-CSCF (or THIG) may encrypt Via and Route information when
acting in topology-hiding mode.

7) All of the S-CSCF elements and various AS may manipulate message
bodies.

8) It appears that the 3GPP "proxy" network will prevent the correct
delivery of many messages using end-to-end protection via S/MIME.

and there's probably a lot more variation that just doesn't come to mind
right now.

--
Dean
----- Original Message -----
From: "Michael Hammer" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>; "²ø¤O¤¤ (ljchuang)" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, May 14, 2002 4:25 PM
Subject: Re: Transparency Top 10 list (was Re: [Sipping] Transparent
B2BUA?)

> > > I would assume that it means that the client doesnt have to point
to
> >it