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) ?
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
