Subject: [Sipping] 3G entities: Proxy or B2BUA?

From: Rohan Mahy <[email-masked]>
Date: Tue, 23 Oct 2001 16:57:21 -0700

Hi Folks,

I've seen a lot of email flying by about various functions needed by 3G on 
their SIP "Proxies".  SIP defines a number of logical *roles*, among them 
Proxy, Registrar, B2BUA, etc.  (If you do such and such, then you are 
acting in such and such role.)

I've listed a couple of the functions that are required by one of the 3G 
SIP servers (the P-CSCF or SIP outgoing "proxy") that automatically put it 
in the B2BUA category.  Note that this is not a *bad* thing, it just helps 
us talk about entities in a consistent way.  You can build a B2BUA that is 
less complex than many true proxies.

- Removal of Via, Route, Record-Route headers: the language about what you 
can do with these headers is a little vague, but one valid interpretation 
is that proxies CANNOT do this.

- Automatic release of sessions: [when a mobile disappears from the radio 
network, the P-CSCF wants to send a BYE.  This is a completely reasonable 
thing to do, but a SIP server that initiates a BYE is *definitely NOT* a 
proxy.]

Why does this matter?  For one, it makes discussions more precise and less 
confusing. For another, it makes opens up some new options architectually 
for implementing the rest of the 3G requirements.  For example, instead of 
the proposed Path header that adds a "vector" or pre-loaded route, the 
P-CSCF could REGISTER on behalf of the UE and expect a body that contains 
this vector in the 200 OK to the REGISTER.  Also, instead of redefining 
registrations and adding special rules for de-registrations, the P-CSCF 
could potentially SUBSCRIBE to the status of the subscriber, and use that 
state information to authorize initial usage and terminate calls when money 
runs out, service is disconnected, or a mobile is stolen.

I can write out a proposal based on this assumption that should meet the 3G 
requriements (from 
http://standards.ericsson.net/sip/drafts/draft-garcia-sipping-3gpp-reqs-00.txt 
).  I'm happy to do this if folks think this is useful, but I would like 
some feedback first.

thanks,
-rohan

_______________________________________________
Sipping mailing list  http://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: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 24 Oct 2001 17:48:58 +0300

Rohan:

1) It is certain that the P-CSCF removes the Via and Record-Route headers and inserts them back in responses. The main reason for that is to reduce the size of the messages when transmitted over the air interface and some sort of security. However, I don't think that doing such a thing moves the P-CSCF to the B2BUA category. The From, To, Call-ID and the rest of the headers are not modified. There is not other "hacking" than removing those (unneeded at the mobile UA) headers.

2) It is not written anywhere that the P-CSCF has to release a session by sending a BYE. I agree with you that such a thing will make the P-CSCF automatically a B2BUA. There are other methods to force the session release, and no one has been agreed in 3GPP at the moment.

The main problem with B2BUA, as it is defined by the bis draft, it that it acts as a UA on both sides. Therefore, it needs to understand every method, header, codec, etc that the UA sends. If it does not understand anything, it has to reject it.

Such a behaviour is not acceptable if we want to progress the development of UAs, create innovative services, etc.

I am not stopping you to write a proposal, I am open to hear proposals. But personally, I don't like B2BUA, and I will try to avoid them unless there is no other chance at all.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002