[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] B2BUA question.
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:howard.hart@zultys.com]
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
>
>
>>-----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
>
_______________________________________________
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