Subject: RE: [Sip] B2BUA question.

From: "Padhye, Chinmay" <[email-masked]>
Date: Thu, 7 Nov 2002 10:56:10 -0800

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

---

From: "A. N. Gautham" <[email-masked]>
Date: Fri, 8 Nov 2002 12:55:09 +0530

Hi,
	The way I understand the definition of a B2BUA, it is combination of 2 User Agents. Their behaviour in all respects is like that of 2 endpoints.
	So, in the following scenario:

		A<--------->((UA-1) (UA-2))<------------>B

		A calls the B2BUA, which consists of UA-1 and UA-2. In response to that, UA-2 initiates a dialog with B. So, for all 'protocol' purposes, A---UA1 and UA-2---B are different dialogs. From this it follows, that the call-ids must be different. Also, since an endpoint would never send two '200 ok's, UA-1 can also not 'forward' more than one '200 ok'.
	Please correct me if I am wrong.
	Hope this helps.
Regards,
A. N. Gautham.

On Thu, 7 Nov 2002 10:56:10 -0800

---

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

Some comments re scenario 2 inline.

Eric

> IMO this should be allowed.

Yes, this is allowed.  The B2BUA at this point would look like:

|----|-----|
|    | UAC |
|UAS |-----|
|    | UAC |
|----|-----|

> IMO this also should be allowed.

No, I don't think this is allowed.  These are 3 completely distinct SIP
dialogs.  In fact, the 200 OK sent by UAS to UA1 should have a different
to-tag from the to-tag received from UA2 and UA3.
_______________________________________________
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