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

From: [email-masked]
Date: Thu, 25 Oct 2001 19:30:19 +0100

Rohan, Georg, Miguel,

	Following this discussion on how a network can release calls at any
time without having to rely on (untrusted) mobile endpoints (which can loose
the radio connection to the network anyway) is important to solve for 3GPP.

	There seems two views:
	<s(n)ip>

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

	<s(n)ip>

If is is possible to define the functionality of a SIP network entity that
can release a call at anytime (e.g. when the pre-paid credit has run out) by
sending a BYE (or any other mid call message in general with correct SIP
parameters i.e. CSeq...) and be transparent for unknown methods, headers etc
etc. , this would be useful to progress the 3GPP work. 

Further information on such an SIP network entity would be useful.  

	<s(n)ip>

	So why we do not allow that a call-stateful proxy in general is
allowed to
	change *only for the generation of a BYE request* its mode of
operation to
	two UAs? We saw some arguments against other proposals - maybe we
can have
	some discussion here why such an approach would not work.

	<s(n)ip>

It may be possible to progress this for simpler requirement initially.

	As a start, the ability for a call-stateful proxy in general is
allowed to
change *only for the generation of a BYE request* would be useful in 3GPP as
this partial feature would help significantly as this would all the network
entities to release calls at any time.

Would this be possible in SIP and is this already defined?

Regards

Sunil
BT
> -----Original Message-----
> From:	Mayer Georg ICM N MC MI E71 [SMTP:[email-masked]]
> Sent:	24 October 2001 17:23
> To:	'Rohan Mahy'; Miguel A. Garcia
> Cc:	[email-masked]
> Subject:	AW: [Sipping] 3G entities:  Proxy or B2BUA?
> 
> Hello Rohan, Miguel et al,
> 
> now it is getting really interesting ...
> <s(n)ip>
> 
> >> 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.
> 
> Yes, BYE is the right solution. Maybe you want to follow me inside an
> example scenario.
> 
> UA-A is attached to P-CSCF1. UA-A is calling UA-B and now UA-A loses raido
> coverage. P-CSCF1 gets aware of that. The situation that we now have is:
> There is no user anymore. 
> 
> Why should P-CSCF1 in this specific case not be allowed to act as a Proxy
> /
> Replacement for UA-A and provide the BYE message for that user? It would
> just turn form call-stateful proxy mode to UA mode and generate the BYE.
> It
> is definitly the endpoint of the session. I see now real problem in
> sending
> a BYE message (as it is the last request in the call) from the physical
> endpoint of the call.
> 
> Well, I know this only solves one problem - but at least it solves
> something. It leaves open the case when S-CSCF needs to release the call. 
> 
> > 
> > >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.
> > 
> >
> Well, I would regard such an entity as something that is not in line with
> the definition in 2543bis-04. I also think that the B2BUA definitoin
> becomes
> very interesting when you look at methods such as COMET or PRACK, even if
> you look at responses to requests. For example when is the first response
> for an incoming INVITE message sent back? (a) When the request came into
> the
> B2BUA? (b) Or when the B2BUA receives the response from UE-B?
> 
> From the defintion in 2543bis-04 I would assume that (a) is the case. If
> that is the case, then the B2BUA is not well-suited for 3GPP.
> 
> If (b) is the case then I would like to know where that has been defined.
> Or
> re-phrased: How can I be sure that there is nobody out there who
> implemented
> (a) instead of (b). In the IMS we want to interconnect with a wide range
> of
> SIP Application Servers - we need to get some more clarification on the
> behavior of the B2BUA therefore, as some of these AS might want to act as
> such an entity. 
> 
> You see - I am not in favour of them. I also think they will delay the
> call
> unnecesarily. And we need that much effort just in order to get a network
> initiated BYE (I attentionally do not say network initiated release -
> because I think that BYE is the right thing to do). 
> 
> So why we do not allow that a call-stateful proxy in general is allowed to
> change *only for the generation of a BYE request* its mode of operation to
> two UAs? We saw some arguments against other proposals - maybe we can have
> some discussion here why such an approach would not work.
> 
> 
> 
> >
> > 
> > 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.
> 
> I would love to have a very clear description of the behavior of a B2BUA -
> if we want it to be different from two real UAs (which I think is the
> current definition - which seems to be open for interpretation, as we have
> different readings of it). 
> 
> Thanks and keep on signaling!
> Georg
> 
> 
> _______________________________________________________
> Georg Mayer - Siemens AG
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Rohan Mahy [mailto:[email-masked]]
> > Gesendet: Mittwoch, 24. Oktober 2001 17:47
> > An: Miguel A. Garcia
> > Cc: Rohan Mahy; [email-masked]
> > Betreff: Re: [Sipping] 3G entities: Proxy or B2BUA?
> > 
> > 
> > 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
> > 
> 
> _______________________________________________
> 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

_______________________________________________
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: Fri, 26 Oct 2001 14:36:29 -0400

> etc. , this would be useful to progress the 3GPP work.

Yes, it's possible.  It's a SIP proxy that for isolated
moments/transactions, acts as a SIP UA.

regards,
Bert

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, October 25, 2001 2:30 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] 3G entities: Proxy or B2BUA?
>
>
> 	Rohan, Georg, Miguel,
>

[snip]