Burren, Martin wrote:
> So, if an UA wants to communicate to a another UA and sends
> its requests to a B2BUA instead of a proxy, will the peer-to-peer
> connection between the caller's and the callee's UA happen or
> will all caller's requests be terminated at the B2BUA (and
> corresponding requests initiated from the B2BUA to the callee's
> UA and vice versa) ?
Since the behavior of B2BUAs isn't well defined there is only so much
that can be said in general.
Assume
X --------- B ---------- Y
where X and Y are UAC and UAS, and B is a B2BUA.
When X sends a message "to Y" via B, then for B to be a B2BUA it
presumably acts as a UA and terminates the request. It then MAY
originate a similar request to Y. If so, then there is a transaction
between X and B, and a different transaction between B and Y. If the
request is dialog establishing then there will be a dialog between X and
B, and another between B and Y.
When the request is an INVITE, a media session will most likely be
established. If so, depending on what B does, there might be a single
media session between X and Y, or there might be a media session between
X and B, and another between B and Y. (Or B may employ a separate media
relay Z, with media sessions between Z and Z, and Z and Y.)
B can try to hide most of this from X and Y. But when dialogs are
established it can't avoid disclosing its own contact address, which can
be a giveaway.
Paul
> mit freundlichen Grüssen / Best regards
>
> Martin Burren
> Customer Support Engineer
>
> KEYMILE AG
> Schwarzenburgstrasse 73, CH-3097 Bern-Liebefeld
> Phone +41 31 377 1395
> Fax +41 31 377 1212
> mailto:[EMAIL PROTECTED]
> http://www.keymile.com
>
>
>>> BE THE FIRST ON THE LAST MILE<<
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:sip-implementors-
>> [EMAIL PROTECTED] On Behalf Of Paul Kyzivat
>> Sent: Wednesday, September 13, 2006 5:23 PM
>> To: Nittin Dutt
>> Cc: 'Naveen Kak'; [email protected]
>> Subject: Re: [Sip-implementors] Difference between a B2BUA andCall
>> statefulproxy
>>
>> Naveen,
>>
>> The question you ask has no meaningful answer, because there is no
>> standard definition of what a B2BUA can (or cannot) do.
>>
>> About all you can say with certainty about a B2BUA is that it contains
>> two UAs. Each of them can do *anything* that a UA is allowed to do.
>> Typically you would expect there to be some correlation between the
>> actions in the two UAs, but there is no definition of what the
>> correlation should be.
>>
>> You can create a B2BUA that behaves much like a proxy, to the point that
>> it is indistinguishable from a proxy most of the time. In the extreme,
>> it looks exactly like a proxy until it decides to send a BYE on both legs.
>>
>> But that is a particular kind of B2BUA, sometimes loosely called a
>> "transparent B2BUA". But AFAIK there is no definition for this within
>> the IETF. The ietf does have some standards for some kinds of B2BUAs:
>> - conference focus
>> - message exploder
>>
>> (I think there must be more.) But these serve specialized purposes
>> rather than being much like proxies.
>>
>> The 3GPP also has some specifications for things that are closer to
>> being transparent B2BUAs.
>>
>> I don't know what your reason for asking is. If you are building a
>> server, and trying to decide whether to make a B2BUA or proxy, and you
>> aren't governed by anything already defined, then you need to figure
>> this out for yourself. Many consider B2BUAs (in proxy-like roles) to be
>> evil. At the very least they are more complex, and have the potential to
>> prevent communication that would be possible if they were proxies. A
>> suitably constructed B2BUA *can* do the kinds of things mentioned below,
>> but doing all those things without messing up anything can be difficult.
>>
>> Paul
>>
>> Nittin Dutt wrote:
>>> Below are the features that B2BUA can provide as against a stateful
>> proxy:
>>> 1. B2BUA can overwrite & modify the SIP headers like Contact, Via,
>>> Record-Route, Route. This could be to implement certain feature or just
>> for
>>> topology-hiding.
>>> 2. B2BUA can be an ALG and provide the NAT traversal solution.
>>> 3. B2BUA can interwork with different network e.g., SIP-H.323
>> interworking.
>>> 4. B2BUA can generate request of their own and can also generate final
>>> responses.
>>> 5. B2BUA can facilitate 3PCC
>>> 6. B2BUA can modify the media parameter. It can do so as to provide the
>>> media policing feature.
>>>
>>>
>>> Regards,
>>> Nittin Dutt
>>> Newport Networks
>>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Naveen Kak
>>> Sent: 12 September 2006 12:48
>>> To: [email protected]
>>> Subject: [Sip-implementors] Difference between a B2BUA and Call
>>> statefulproxy
>>>
>>> Could anybody explain the difference between a B2BUA and a call stateful
>>> proxy?
>>>
>>> Thanks
>>> Naveen
>>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Stephen
>>> Paterson
>>> Sent: Tuesday, September 12, 2006 2:32 PM
>>> To: Mahipati Deshpande; [email protected]
>>> Subject: Re: [Sip-implementors] When will send the PRACK
>>>
>>> Hi,
>>>
>>> We had a similar problem last week. RFC 3262 states:
>>>
>>> The provisional response to be sent reliably is constructed by the
>>> UAS core according to the procedures of Section 8.2.6 of RFC 3261.
>>> In addition, it MUST contain a Require header field containing the
>>> option tag 100rel, and MUST include an RSeq header field.
>>>
>>> so both the RSeq and the Require header are needed in any reliable
>>> provisional response.
>>>
>>> Cheers
>>>
>>> Steve
>>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] Behalf Of Mahipati
>>> Deshpande
>>> Sent: 12 September 2006 05:33
>>> To: [email protected]
>>> Subject: Re: [Sip-implementors] When will send the PRACK
>>>
>>>
>>> Hi Bin,
>>>
>>> IFAIK, Require header should not be there in any response (check table 3
>>> in RFC
>>> 3261). UAS is going to insert RSeq header if it is willing to receive
>>> PRACK
>>> (provided, UAC supports it). So I think oSIP code is right.
>>>
>>> Regards,
>>>
>>>
>>> --- Bin Chen <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi,
>>>>
>>>> IMO when the header includes "Require: 100REL" then the PRACK should
>>>> be sent, but I found the oSIP implementation do a trick that when it
>>>> find the response head includes a RSeq field.
>>>>
>>>> It is right?
>>>>
>>>> {
>>>> osip_header_t *rseq;
>>>>
>>>> osip_message_header_get_byname (je->response, "RSeq", 0, &rseq);
>>>> if (rseq != NULL && rseq->hvalue != NULL)
>>>> {
>>>> /* try sending a PRACK */
>>>> osip_message_t *prack = NULL;
>>>> int i;
>>>>
>>>> eXosip_lock ();
>>>> i = eXosip_call_build_prack (ca->tid, &prack);
>>>> if (i != 0)
>>>> {
>>>> OSIP_TRACE (osip_trace
>>>> (__FILE__, __LINE__, OSIP_WARNING, NULL,
>>>> "Failed to build PRACK request\n"));
>>>> } else
>>>> {
>>>> eXosip_call_send_prack (ca->tid, prack);
>>>> }
>>>>
>>>> eXosip_unlock ();
>>>> }
>>>> }
>>>>
>>>> --
>>>> Chief Programmer,
>>>> Abai Studio,
>>>> China
>>>> Focus on Linux, VoIP, Entertainment
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> [email protected]
>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>
>>>
>>> Mahipati Deshpande
>>>
>>>
>>>
>>> __________________________________________________________
>>> Yahoo! India Answers: Share what you know. Learn something new
>>> http://in.answers.yahoo.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
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>>
>>>
>>> ---------------
>>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient (or have received this e-mail in error)
>> please notify the sender immediately and delete this e-mail. Any
>> unauthorized copying, disclosure or distribution of the contents in this e-
>> mail is strictly forbidden.
>>> ---------------
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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
