Subject: RE: [Sip] B2BUA question.

From: Juan Luis Esteban <[email-masked]>
Date: Thu, 7 Nov 2002 12:55:41 +0100

Session Controllers deployed at the edge of the IP network or at ITSP
peering points are another example of B2BUA entities.
SCs allow layer 3 topology hiding, admission control... QoS features are
also being added by some vendors.

-----Mensaje original-----
De: Bert Culpepper [mailto:[email-masked]]
Enviado el: jueves, 07 de noviembre de 2002 3:23
Para: Padhye, Chinmay
CC: [email-masked]
Asunto: 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
_______________________________________________
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: Juan Luis Esteban <[email-masked]>
Date: Fri, 8 Nov 2002 10:32:53 +0100

Hi,

Regarding scenario 1, I think you´re right.
per RFC326, CIDs must be globally unique, and dialog IDs at each UA consist
of Call-ID + local tag + remote tag. Since the B2BUA mantains 2 dialogs, one
as UAS and another one as UAC, I agree that Call-IDs must be different.

Regarding scenario 2, dialog at UA1 will be instantiated based on the first
200OK received with the to tag. I think that only one dialog will be
created/mantained by UA1.
Nevertheless, it should be possible that the B2BUA create 2 dialogs with UA2
and UA3 and perform some kind of audio mixing, which is an implementation
choice.
I would think that scenario 2 could be though of as a simple conferencing
bridge implemented with a B2BUA. (?)
Nevertheless, I think that the second 200OK from B2BUA to UA1 should not be
sent. B2BUA does not need to mantain two dialogs at the UAS side in this
example, nor does UA1.

regards,

-----Mensaje original-----
De: Padhye, Chinmay [mailto:[email-masked]]
Enviado el: jueves, 07 de noviembre de 2002 19:56
Para: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis
Esteban
CC: [email-masked]
Asunto: 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,
> 
> >     'Since it is a concatenation of a UAC and UAS, no explicit
definitions are needed for its behavior."

-- 
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: Juan Luis Esteban <[email-masked]>
Date: Fri, 8 Nov 2002 18:47:27 +0100

I think that both cases should be possible,

case 1) could be an example of a  double stage dialing scenario where B2BUA
is handling both RTP streams:
eg. user dials in, is prompted for PIN/Destination Number, and afterwards
the second INVITE is sent by the UAC side to UA2, and B2BUA chooses to proxy
RTP to perform admission, RTP steering,aggregate RTP streams from/to
different UAs, etc...
case 2) could be a single stage dialing scenario.
In both cases dialogs on both sides are established and mantained by the
B2BUA, so the behavior is consistent with the B2BUA term. 

also, in case 2) B2BUA could decide to proxy RTP, or not, depending on SDP
info in the second INVITE and in 200OK back to UA1.

RTP streams could also flow directly between UA1 and UA2 in scenario 1) , in
which case the UA1-B2BUA Dialog should be modified : Re-INVITE should be
sent from B2BUA back to UA1 after receiving 200OK from UA2.

My opìnion is that it is implementation/service specific how dialogs on both
sides are coupled, and whether B2BUA handles RTP or not.

-----Mensaje original-----
De: Howard Hart [mailto:[email-masked]]
Enviado el: viernes, 08 de noviembre de 2002 17:55
Para: Kaul, Amit
CC: Padhye, Chinmay; Bert Culpepper; Gonzalo Camarillo; Jonathan
Rosenberg; Juan Luis Esteban
Asunto: Re: [Sip] B2BUA question.

The question that always comes to my mind on this is how independent are 
the 2 UA's? i.e. - if a B2BUA is literally 2 UA's cobbled together, does 
this mean they are:

1) 100% standalone, independent entities that just happen to be tied 
together:

UA1              B2BUA	           UA2
|-- INVITE ------->|                |
|<-----200 OK------| -- INVITE ---->|
|-- ACK ---------->|<-----200 OK----|
|                  |-- ACK -------->|

or 2) must they operate in lockstep to add some sanity to the process?

UA1              B2BUA	           UA2
|-- INVITE ------->|                |
|                  | -- INVITE ---->|
|                  |<-----200 OK----|
|<-----200 OK------|                |
|-- ACK ---------->|                |
|                  |-- ACK -------->|

Personally, I vote for 2). Doesn't make sense to create a UA1 to UA2 
dialog, "virtual" or otherwise, until UA2 has opted in, but where is 
this documented? Or maybe option 1) does make sense where the B2BUA 
functions as a media/RTP gateway also? Does this make it something else, 
or is there yet another logical entity we're missing--B2BUA Media 
Gateway, too much layer mixing here?

Howard Hart

Kaul, Amit wrote:
> 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
> 
> 
>>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,
>>
>>	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.
>>	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
>>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? 
>>
>>- Is the B2BUA allowed to generate two responses towards UA1 
>>(with different to-tags)? 
>>
>>>        So the B2BUA logical entity is a combination of 
>>
>>"ONLY" the UAC and UAS logical entities. Is this an accurate 
>>statement?
>>
>>>Regards,
>>>
>>>Chinmay
>>>
>>>I'll provide my opinion on why this term was included in 
>>
>>RFC3261, other
>>
>>>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
>>
>>>specification.  This particular combination became common 
>>
>>enough that (I
>>
>>>presume) the authors thought it should be mentioned in the 
>>
>>new RFC, to
>>
>>>>    '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
>>>>Use [email-masked] for new developments on the 
>>>
>>application of sip
>>
>>>>