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