[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Sip] B2BUA question.



I agree that we might want to limit our discussion only within SIP
properties 
of B2BUA to get some common understanding of B2BUA as a SIP logical entity. 

In addition to few queries which Chinmay has pointed out,I can think of 
some basic points that need to be clarified/discussed about B2BUA :

   - Can B2BUA behave as a forwarding agent like Proxy, witout initiating 
     a new dialog ?

   - Can B2BUA decide to Fork like a Proxy ?

   - Can B2BUA decide to switch between UAC/UAS and Proxy functionality like

     Proxy and Redirect functionality. 

   - Is it mandatory for B2BUA to be always call-stateful ?

   - Since a UA can be stateless (RFC3261 Sec 8.2.7), is stateless B2BUA 
     also possible ?

   - Finally, can B2BUA be called as a combination of "Proxy and UAS/UAC"  
     or just "UAS/UAC" combo ?

I know that the above list is not complete and possibly might have been
answered 
before, but I do hope that this thread will bring some consensus on the more

concrete "SIP definition" of B2BUA. 

I suggest that, to start with, there be some kind of FAQ regarding B2BUA 
documented somewhere. Any Comments ?

thanks
__amit

> -----Original Message-----
> From: Padhye, Chinmay [mailto:chinmay.padhye@intel.com]
> Sent: Friday, November 08, 2002 12:26 AM
> To: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis
> Esteban
> Cc: sip@ietf.org
> Subject: RE: [Sip] B2BUA question.
> 
> 
> Hello,
> 
> 	My response is inline starting with [Chinmay].
> 	
> Regards,
> 
> Chinmay
> 
> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Thursday, November 07, 2002 12:04 AM
> To: Padhye, Chinmay
> Cc: Bert Culpepper; sip@ietf.org
> Subject: Re: [Sip] B2BUA question.
> 
> 
> Hi,
> 
> I do not understand what you mean by "ONLY", but I will take 
> a stab at a
> response anyway. If by "ONLY" you mean that it does not 
> implement other
> protocols, the answer is no. A B2BUA can receive a SIP 
> request acting as
> a SIP UAC, send an LDAP query acting as an LDAP client, and 
> then send a
> SIP request acting as a SIP UAC.
> 
> ----------------------------------
> [Chinmay]
> 
> 	I think its better if we separate logical entities with 
> physical entities or applications that contain/behave as 
> multiple logical entities. An application may contain a B2BUA 
> logical entity, a LDAP client, a proxy entity, a registrar 
> entity, etc. A physical entity may contain many such applications. 
> 
> 	My statement - 'the B2BUA logical entity is a 
> combination of "ONLY" the UAC and UAS logical entities. Is 
> this an accurate statement?', was meant only for the B2BUA 
> logical entity and not for the application.
> 
> 	Hence in the above example the B2BUA logical entity 
> cannot send the LDAP query. The LDAP client, which is part of 
> the same application, sends the LDAP query.
> ----------------------------------
> 
> A B2BUA handles two dialogs, and it behaves as a UA for both dialogs.
> The B2BUA typically uses information in requests or responses in one
> dialog to create requests or responses in the other one. An 
> example of a
> B2BUA is a 3rd party call controller.
> 
> ----------------------------------
> [Chinmay]
> 
> 	I need some more clarifications on some scenarios. 
> 
> 	Consider the following scenarios.
> 
> Scenario 1 -
> 
> 	UA1			B2BUA			UA2
> 	|-- INVITE -------> | 			 |
> 	|	CID:1		  | -- INVITE ---->|
> 					CID:x
> 
> 	In the above scenario can 'x' take the value 1?
> 
> 	IMO this x MUST not be equal to 1, because the UAC part 
> of the B2BUA must not use CID:1 to generate the outgoing 
> INVITE. Is this right.
> 
> Scenario 2 -
> 
> 	I am not sure if this part of the email belongs here or 
> in the implementers list. Let me know if I should move this 
> part of the email to the implementers list.
> 
> UA1			B2BUA			UA2		UA3
> |-- INVITE -------> | 			 |		  |
> |	CID:1		  | -- INVITE ---->|		  |
> |			  |	CID:2	       |		  |
> |			  |	             |		  |
> |               	  | -- INVITE ----------------->|
> |			  |	CID:3		 |		  |
> |			  | 			 |		  |
> |			  | <-- 200 OK --- |		  |
> | <---- 200 OK ---- |			 |		  |
> |			  | <-- 200 OK -----------------|
> | <----- 200 OK --- |			 |		  |
> 	?????????
> 	Can this be forwarded.
> 
> In this scenario the B2BUA, on receiving the INVITE request 
> from UA1, generates new INVITE request to two UAs, UA2 and 
> UA3. (A similar scenario will occur if a downstream proxy 
> forks and receives multiple 200 OKs.)
> 
> - Can the B2BUA generate two INVITE/Requests, for one 
> incoming INVITE/Request? Is this allowed by the 
> protocol/definition of B2BUA? 
> 
> IMO this should be allowed. 
> 
> Now both the UAs respond with 200 OK responses.
> 
> - Is the B2BUA allowed to generate two responses towards UA1 
> (with different to-tags)? 
> 
> IMO this also should be allowed.
> 
> ----------------------------------
> 
> Regards,
> 
> Gonzalo
> 
> 
> "Padhye, Chinmay" wrote:
> > 
> > Hello,
> > 
> >         Thanks for the reply.
> > 
> >         So the B2BUA logical entity is a combination of 
> "ONLY" the UAC and UAS logical entities. Is this an accurate 
> statement?
> > 
> > Regards,
> > 
> > Chinmay
> > 
> > -----Original Message-----
> > From: Bert Culpepper [mailto:bertculpepper@netscape.net]
> > Sent: Wednesday, November 06, 2002 6:23 PM
> > To: Padhye, Chinmay
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] B2BUA question.
> > 
> > Hi,
> > 
> > I'll provide my opinion on why this term was included in 
> RFC3261, other
> > folks may provide different/better reasons.
> > 
> > The previous RFC defined UAC, UAS, Registar, Proxy, and 
> Redirect Server
> > logical entities.  As services (both legacy and new) were 
> designed using
> > SIP, it was determined that a combination of defined 
> logical entities
> > was needed to implement the services and still be compliant with the
> > specification.  This particular combination became common 
> enough that (I
> > presume) the authors thought it should be mentioned in the 
> new RFC, to
> > avoid mis-interpretation.
> > 
> > Regards,
> > Bert
> > 
> > Padhye, Chinmay wrote:
> > 
> > > Hello,
> > >
> > >     This is from the definition of B2BUA from RFC 3261 -
> > >
> > >     'Since it is a concatenation of a UAC and UAS, no 
> explicit definitions are needed for its behavior."
> > >
> > >     Since the behavior of a B2BUA is the same as the 
> behavior of a UAC/UAS, what was the need for defining a new 
> logical entity - B2BUA? I am trying to understand the 
> motivation behind adding this definition in the RFC.
> > >
> > > Regards,
> > >
> > > Chinmay
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the 
> application of sip
> > >
> > >
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip