[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] B2BUA question.
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:chinmay.padhye@intel.com]
Enviado el: jueves, 07 de noviembre de 2002 19:56
Para: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis
Esteban
CC: sip@ietf.org
Asunto: 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