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

From: Rohan Mahy <[email-masked]>
Date: Wed, 24 Oct 2001 08:46:57 -0700

Hi,

Comments inline...

---- Original message ----
>Date: Wed, 24 Oct 2001 17:48:58 +0300
>From: "Miguel A. Garcia" <[email-masked]>
>Subject: Re: [Sipping] 3G entities:  Proxy or B2BUA?
>To: Rohan Mahy <[email-masked]>
>Cc: [email-masked]
>
>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.

I believe we agree to disagree here.  As the spec is 
ambiguous on this point we can leave it at that or ask for 
some consensus from the SIP WG.

>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.

If it looks like a BYE, and feels like a BYE, and smells 
like a BYE.....   ;-)

Since BYE would do exactly what 3G intends, I would like to 
pursue this option first.

>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.

This assumption is fortunately not correct.  It is possible, 
reasonable, and legal to implement a B2BUA that 
transparently passes headers, method, and bodies that it 
does not directly understand.  An anonymizer is a perfect 
example of such a B2BUA--it only needs to understand a few 
headers, plus the SDP, and pass the rest transparently.

The main advantage of a B2BUA in this environment is that it 
can keep per-call-leg state and can be involved in mid-call 
signaling.  As a proxy is only involved in transactions, it 
can only handle pre-call features.  A B2BUA can insert SIP 
messages (for example BYE messages), run timers, and may 
change the required headers: (To, From, Call-ID, CSeq, 
Via).  

Also, there may be resistance to keeping lots of state on 
the B2BUA.  It is possible (though a bit complicated) to 
implement a B2BUA that is completely call stateless, by 
pushing encrpyted call-state to the edges.

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

I agree that an *implementation* of a B2BUA with this 
property would be unacceptable.

>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.

Please let me know if you still object to the type of B2BUA 
I have described.  I would like to discuss how you could use 
this architecture to implement more of the 3G requirements.

thanks,
-rohan

>/Miguel
>
>
>Rohan Mahy wrote:
>> 
>> 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
>
>-- 
>Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                        Jorvas, Finland
>mailto:[email-masked]     Phone:  +358 9 299 
3553
>mailto:[email-masked]        Mobile: +358 40 
5140002

_______________________________________________
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: "Bert Culpepper" <[email-masked]>
Date: Wed, 24 Oct 2001 13:15:33 -0400

I agree with Rohan. The functionality discussed in the previous thread is
already nicely provided by SIP.

I encourage the 3gpp folks to not get hung up on SIP terms/functional
entities.  It is my belief that any device sitting between two endpoints
that is providing some call service will many times have more than one
SIP role.  And the role will change during a call.  This is perfectly
legitimate, and the SIP spec allows it.  And doesn't mandate a whole
bunch of otherwise un-needed functionality.

I encourage Rohan to go forward with his proposal.  I'd hate to see some
application/function "modify" SIP unnecessarily.  I want my SIP device to
work with these new applications and networks.

Regards,
Bert

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 25 Oct 2001 10:30:27 +0300

Hi:

More comments inline.

> >To: Rohan Mahy <[email-masked]>

[snip]

> If it looks like a BYE, and feels like a BYE, and smells

Well, I wasn't suggesting a new method or something like that.
I was more thinking of other alternatives, like the P-CSCF 
dismissing the bearers or something like that. But I never
thought of cheating SIP.

> pursue this option first.

Fair enough. But it may break SIP. I don't want to break any
SIP implementation.

> headers, plus the SDP, and pass the rest transparently.

I don't think it is possible to transparently pass headers, 
methods, bodies, etc. For instance, manyfolks already specifies
actions when the a=qos attribute is present in SDP with the 
parameter "confirm" (COMET is triggered). The B2BUA will need
to understand the confirm to trigger the COMET. How is this
going to interact with the QoS reservation?

In general, I think the B2BUA is evil. It needs to understand
absolutly everything, and therefore, is anti-transparent.
You can design a B2BUA that forwards some headers, methods, 
etc. But if the B2BUA passes everything that is not understood
transparently (like a proxy does), then what is the mission of
the B2BUA? 

> change the required headers: (To, From, Call-ID, CSeq,

Yes, I understand that. The question is: is all needed?
Are we willing to pay the price of having 6 or more B2BUA
(that we don't know the behaviour for unknown headers,
methods, bodies, etc) in the path of the call just to be 
able to send a BYE? IMHO the price is very expensive.

> pushing encrpyted call-state to the edges.

Works fine in DCS. But in 3G wireless, where the terminals
will be limited in memory, coverage, bearers, etc., it is
not desirable to push states to the terminals.

> this architecture to implement more of the 3G requirements.

I think the concept of a B2BUA is clear in bis-04. It is just
two UA linked by some logic above. As such, the B2BUA needs to
behave as two UAs. If you are thinking of something else, 
perhaps it is not a B2BUA, but other thing. If you are thinking
of a stateless B2BUA, perhaps it is not a B2BUA, and further
more, probably not acceptable for 3G networks.

/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