Hi Paul, I am not trying to build a BBUAs, we already have one...but are caught up in a issue where in a calls from PSTN user do not land to voice mail if the user is out of network due to abrupt shutdown of the system where the client is running or PC going to hibernating mode. Or network issue. Any suggestion from implementation point view?
Regards Sunil Verma ESN 6-343-8884 -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 5:31 PM To: Daniel Corbe Cc: Sunil Kumar Verma; 'Sarkar, Uttam'; [email protected] Subject: Re: [Sip-implementors] 180 Ringing from Proxy(BBUA) 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 > 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
