[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] B2BUA question.
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
"Padhye, Chinmay" <chinmay.padhye@intel.com> wrote:
> 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