Just to add on to Nitin's points, B2BUA could be used to provide topology hiding (THIG) whereas CSF might not be able to do so...
In simple terms (wrt implementation perspective) you can think of B2BUA is something similar to response context in state-full proxies, but does lot more than what RC would do... Thanks, Nataraju A B > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of Nittin Dutt > Sent: Tuesday, September 12, 2006 10:31 PM > To: 'Naveen Kak'; [email protected] > Subject: Re: [Sip-implementors] Difference between a B2BUA and > Callstatefulproxy > > > 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
