Hello Russ , Just check this link out ... There are two solutions , either the UAS can implement it's own "ring timeout" ... Also the proxy is supposed to send a CANCEL in case timer C expires ... http://bugs.sipit.net/show_bug.cgi?id=706
Regards , Sayan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Russ Daigle Sent: Friday, December 01, 2006 6:43 AM To: Siddhartha Bhakta Cc: [email protected] Subject: Re: [Sip-implementors] Clearing up of 486 Busy when INVITE callerdies... Thanks for your response. Remember, in my scenario the UAC died. Therefore, it will not be having any timers that expire nor will it send any CANCELs. Therefore, it is completely dependent on the proxy B or UAS C to clean up. (And please no responses about UAC solutions to this problem, because the whole point is to test proxy/UAS scenarios with somewhat flaky UACs. It "dies" because it is suppose to!:) I can imagine that a UAS can be implemented to just let the phone ring and ring and ring. Is there anywhere in any RFC that indicates UAS's or proxies should terminate an incoming call if it isn't answered within a certain time? Thinking of analog phones, as long as the caller doesn't hang up and the callee doesn't have answering- machine/voicemail, the phone will keep ringing and ringing and ringing at the callee. So... I am definitely encountering an indefinite 486 busy response with a couple different SIP phones (and an analog phone connected to a cisco gateway). This 486 never clears up, unless the phone is answered (and hung up). Would you expect a transaction stateful proxy would cancel a call if it rings for so long without being answered? I wish the answer was yes, but I suspect the answer is that typical UAS and proxy will just let the phone continue ringing.... hence anybody else calling will encounter a 486 busy. This perhaps is more of a testing problem, than real-world problem. However, my situation is a test-setup, hence is a real-world problem for me. Nonetheless, for automation testing, I really wish there was a way to have the UAS or proxy clear up the line in an automatable manner. -Russ On Nov 30, 2006, at 4:07 PM, Siddhartha Bhakta wrote: > > >> Now SIP phone A dies and never comes back. >> Furthermore, nobody is >> available to answer C, so it keeps ringing, and ringing, and >> ringing...... > > > Typically UAS (of C) shall start a timer on receiving INVITE. if C > user does not answer the call within that timer, then UAS shall send > back appropriate error response and shall stop Ringing. On receiving > this error response, UAC shall terminate the call. This error response > shall also terminate the transaction of any stateful proxy(Proxy B in > your case) in the path. > > The UAC also starts a timer after initiating the call with INVITE. If > that timer expires before receiving 200 OK then it shall send CANCEL > to terminate the INVITE transaction. In fact, 487 response of INVITE > (followed by INVITE) terminates the INVITE dialog. > > Therefore, depending on which timer expires first, either A shall send > CANCEL to cancel INVITE or C shall send error response to terminate > INVITE dialog in your case. > >> Now if SIP Phone A comes back up and calls C again (through B), we >> will get a 486 busy. > > If UAC and UAS starts the timer as specified above, SIP phone shall > not get 486 Busy in your described scenario. > > >> The question is when will the 486 busy clear up? > > Not sure whether your are asking about UAC or UAS. The > 486 shall definitely clear up the dialog at UAC initiated by INVITE. > But 486 of new INVITE shall not typically impact any exiting orphaned > dialog. > > >> Is the proxy and C suppose to clear up after a time >> and cancel the call? (What if A >> called C directly.... since A died, who would CANCEL the call on C?) > > If the proxy is the transaction stateful proxy then it must start a > timer so that it can clean-up its transaction in case network > failure(on the expiry). > > > > > > __________________________________________________________ > 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 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
