I just noticed this has been sitting unanswered for awhile. Responses
inline.
Paul
Daniel Corbe wrote:
>
> On Mar 8, 2007, at 6:39 PM, Paul Kyzivat wrote:
>
>>
>>
>> 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!
>
> It does, really. Where does it say otherwise?
The above is all it says about B2BUAs - it doesn't attempt to say
explicitly say much about them. But the above *implicitly* says quite a
bit about them. A B2BUA a UA, and a proxy is a proxy. If you compare the
descriptions of UA and proxy, you will find that they are quite
different. Being a B2BUA doesn't reduce those differences.
>> 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.
>
> Well that's a good point... but in this type of scenario why would the
> B2BUA send a 180 and not simply a 200 OK so it can start playing its
> media stream?
I don't know - you are the one that asked the question. You asked if it
*can*. I guess technically I can't answer that without a familiarity
with its implementation. I can say the it *may* send a 180. But I think
the question you really want answered is whether it *should* send a 180
before the call is answered by the far end. That will be a judgment
call, and will depend on detailed knowledge of what is going on.
> Cases in which a B2BUA needs to play media (such as an error message)
> but don't want to generate a billable call can play their media stream
> in a 183 but again this isn't ring tone.
>
> In either case we're talking about mediation not initiation.
I gather you have a particular concept that you are calling "mediation".
I don't know what you mean by that so I can't comment.
>>> 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.
>
> Sure I do, and I wish I had more information to give to you.
So what is your problem? Are you trying to build this B2BUA? If so then
I would hope you would know what you want it to do. Or are you building
one of the UAs and having to cope with odd behavior of a B2BUA you have
no control over?
Paul
>> 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
