Daniel Corbe wrote:
> What are you trying to fix? Are you not getting ring indicator tone
> back from one of your carriers?
>
> In practice you shouldn't be generating any provisional responses except
> for 100 Trying. In the voice world at least this is generally regarded
> as a bad idea.
That is a good recommendation for a proxy. It is presumptive to make
such a statement for a B2BUA.
> RFC3261 specifically makes no distinction between a proxy and a B2BUA
> other than this:
> 6 Definitions
>
> Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
> logical entity that receives a request and processes it as a
> user agent server (UAS). In order to determine how the request
> should be answered, it acts as a user agent client (UAC) and
> generates requests. Unlike a proxy server, it maintains dialog
> state and must participate in all requests sent on the dialogs
> it has established. Since it is a concatenation of a UAC and
> UAS, no explicit definitions are needed for its behavior.
>
> So "proxy" and "b2bua" are very ambiguous. Based on that definition,
> one would be going out on a limb to say "A B2BUA can do more than a
> proxy can."
You make it sound like 3261 considers them to be almost the same thing!
Nothing could be further from the truth. 3261 makes very clear
distinctions between a Proxy and a UA. A B2BUA *is* a UA, so in general
you must assume that is how it acts. E.g. if it wants to *answer* a call
itself, before sending another call out, it can do that.
> The differentiator between a B2BUA and a Proxy Server IMHO is the
> session mediation features you typically find in a B2BUA such as call
> routing, answer/disconnect supervision, etc. Mediation is not defined
> by RFC3261, only Initiation.
You have a particular flavor of B2BUA in mind. Many people thing this is
the only kind - one that often acts in a way similar to how a proxy
would act, except when it wants to violate one of the rules that proxies
must follow.
These are sometimes called "transparent B2BUAs" where the model for
transparency is a Proxy. But the term is still ambiguous. If it is to
achieve full transparency it will actually be a proxy. To do more than a
proxy it must give up some degree of transparency. Implementors have
varying ideas about what they need to do and what aspects of
transparency they are willing to give up.
The original poster here seems to have that in mind. If it was to be
fully transparent it would only forward on responses in the way a proxy
would, so it probably wouldn't send a 180 before receiving something
from the UAS. Because it is a B2BUA, it MAY do this, and if suitably
constructed it also CAN do it. The question is whether it SHOULD do it.
That depends on the goals.
Paul
> An interesting draft to see would be "Session Mediation with the Session
> Initiation Protocol and Session Description Protocol"
>
> Cheers
> -Daniel
>
> On Mar 8, 2007, at 4:46 PM, Sunil Kumar Verma wrote:
>
>>
>> Thanks Paul and Uttam.
>>
>> I have B2BUA, so we can say that B2BUA can generate 180 RINGING for
>> the call which are yet to be answered at the far end??
>> Caller receives ringback tone only if the called party is ringing..
>> Think of a scenario..
>> if the called user has voice mail configured and due to some network
>> problem his client
>> ,after registering to B2BUA, is out of network. The B2BUA still
>> consider
>> that the user is available
>> and if somebody tries to reach that user he hear deaf silence and then
>> after 10 to 15 sec the call goes to Voice mail.
>> Is there any way we can avoid the deaf scilence in case of B2BUA?
>>
>> Regards
>> Sunil Verma
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, March 08, 2007 3:36 PM
>> To: Sarkar, Uttam
>> Cc: Sunil Kumar Verma; [email protected]
>> Subject: Re: [Sip-implementors] 180 Ringing from Proxy(BBUA)
>>
>>
>>
>>
>> Sarkar, Uttam wrote:
>>> Nope. It can send 100 Trying.
>>> 180 would have "totag" that would create a dialog. Without getting any
>>> reponse from client B. You can't create a dialog.
>>
>> That is correct answer for a proxy. For a B2BUA almost anything is
>> possible. It depends on what the B2BUA is trying to accomplish.
>>
>> Paul
>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Sunil
>>> Kumar Verma
>>> Sent: Thursday, March 08, 2007 1:52 PM
>>> To: [email protected]
>>> Subject: [Sip-implementors] 180 Ringing from Proxy(BBUA)
>>>
>>>
>>>
>>> Hi,
>>>
>>> In case of BBUA, is it possible for proxy to generate 1xx response
>>> for an INVITE, before receiving any reply from
>>> terminating SIP client.
>>> For Ex. SIP client A calling another SIP client B, and before
>>> receiving any reply from the SIP client B for the initial
>>> INVITE, can proxy generate 180 RINIGING reply?
>>>
>>> Thanks
>>> Sunil verma
>>>
>>>
>>>
>>>
>>>
>>>
>>> The information contained in this electronic message and any
>>> attachments to this message are intended for the exclusive use of the
>>> addressee(s) and may contain proprietary, confidential or privileged
>>> information. If you are not the intended recipient, you should not
>>> disseminate, distribute or copy this e-mail. Please notify the sender
>>> immediately and destroy all copies of this message and any
>>> attachments.
>>>
>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>> should check this email and any attachments for the presence of
>>> viruses. The company accepts no liability for any damage caused by any
>>> virus transmitted by this email.
>>>
>>> www.wipro.com
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
>>
>>
>> The information contained in this electronic message and any
>> attachments to this message are intended for the exclusive use of the
>> addressee(s) and may contain proprietary, confidential or privileged
>> information. If you are not the intended recipient, you should not
>> disseminate, distribute or copy this e-mail. Please notify the sender
>> immediately and destroy all copies of this message and any attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient
>> should check this email and any attachments for the presence of
>> viruses. The company accepts no liability for any damage caused by any
>> virus transmitted by this email.
>>
>> www.wipro.com
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
