Subject: RE: [Sip] B2BUA question.

From: "Kaul, Amit" <[email-masked]>
Date: Thu, 7 Nov 2002 21:53:06 -0800

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:[email-masked]]
> Sent: Friday, November 08, 2002 12:26 AM
> To: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis
> Esteban
> Cc: [email-masked]
> Subject: RE: [Sip] B2BUA question.
> 
> 
> Hello,
> 
> 	My response is inline starting with [Chinmay].
> 	
> Regards,
> 
> Chinmay
> 
> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 12:04 AM
> To: Padhye, Chinmay
> Cc: Bert Culpepper; [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, November 06, 2002 6:23 PM
> > To: Padhye, Chinmay
> > Cc: [email-masked]
> > 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 [email-masked] for questions on current sip
> > > Use [email-masked] 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 [email-masked] for questions on current sip
> > Use [email-masked] 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 :  [email-masked]
> 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Cheung <[email-masked]>
Date: Fri, 08 Nov 2002 07:29:05 -0500

Some of my opinion below.  I agree that there is a need for some common
understanding of B2BUA.  Perhaps an informational I-D is in order.
Eric

>    - Can B2BUA behave as a forwarding agent like Proxy, witout initiating

No.  Remember B2BUA, Proxy etc are logical entity.  A physical
implementation (say call it a SIP server) may be a combination of a
B2BUA and a Proxy, and an INVITE may be handled by the Proxy part.

>    - Can B2BUA decide to Fork like a Proxy ?

A B2BUA can certainly make 2 outbound calls on receipt of 1 incoming
call.  But the call flow is different from a Proxy e.g. Chinmay scenario
2
>      Proxy and Redirect functionality.
As above, a SIP server that implements the B2BUA, Proxy and Redirect
server logical entities can do this.
>    - Is it mandatory for B2BUA to be always call-stateful ?

Yes, I think so.
>    - Since a UA can be stateless (RFC3261 Sec 8.2.7), is stateless B2BUA

The UAS part of a B2BUA can behave in the way describe in sec 8.2.7 to
challenge unauthenticated requests.

>      or just "UAS/UAC" combo ?

See above.  I think it is cleaner to keep the logical entities as clean
as possible.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 8 Nov 2002 16:23:22 -0500

> I agree that we might want to limit 
> our discussion only within SIP properties 
> In addition to few queries which Chinmay 
> has pointed out, I can think of 

A B2BUA can do everything that a UA can.  
In the process, the B2BUA can choose to 
proxy nothing or most everything over the 
multiple dialogs.

If someone wants to perform an exhaustive 
evaluation of proxy-vs-B2BUA, that
is more of a sipping issue since it deals
with network deployment.  However such
an evaluation gets complicated because
each vendor can code or configure their
B2BUA to varying degrees concerning what
information should be proxied.  Such a
decision is determined based upon 
the assigned task/service of the B2BUA.

Some products can even assume a 
dialog-stateful proxy role within a 
dialog; then it can morph into a B2BUA 
when it desires to start sending requests 
within established halves of a dialog.
(e.g. a dialog-stateful proxy which wants to 
release both halves of a dialog and can 
satisfy the authentication challenges.)  
After morphing into a B2BUA, it must be
careful within the 2 halves of the dialog
since it has trampled on another UA's 
CSeq space.