Hi, As per RFC Retry after timer is different for UAS and UAC and hence they both are not going to ReTry after same interval. I hope I got you question right. I am not able to see section in Red.
Regards Sunil Verma ESN: 877-5050 Ph: +919731245000 -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Dushyant Godse Sent: Wednesday, April 28, 2010 10:07 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] How to resolve 491 request pending cross over onRe-INVITEs HI I am sure this has been asked many times but I could not find a definitive thread on how to resolve this. Moreover RFC 3261 section 14.2 is vague about resolving race conditions for Re-INVITEs. You could directly skip over to offending section (in red) below for the issue in question. Here is the call flow UA1 UA2 ---INVITE (call leg#1)--- > < -- 100 trying (call leg#1)-- < -- 180 ringing (call leg#1)-- < -- 200 OK (call leg#1)-- ---ACK (call leg#1)--- > <--- RTP established--- > UA2 now initiates a new dialog with UA1 hybrid switch to call a 3rd party to which the call should get bridged UA1 UA2 < -- INVITE (call leg#2)-- ---100 trying (call leg#2)--- > ---180 ringing (call leg#2)--- > ---200 OK (call leg#2)--- > < -- ACK(call leg#2)-- UA2 now performs re-INVITE on call leg #1 and #2 to bridge RTP between caller and transfer target on UA1 Switch. UA1 UA2 < -- INVITE w/o SDP (call leg#2)-- ---100 trying (call leg#2)--- > ---200 OK w/ SDP (call leg#2)--- > < -- INVITE w/ SDP (call leg#1)-- ---100 trying (call leg#1)--- > ---200 OK w/ SDP(call leg#1)--- > < -- ACK w/ SDP(call leg#2)-- < -- ACK (call leg#1)-- Offending section Now UA2 receives re-invite w/ SDP on call leg #1 from UA1. UA1 extracts SDP from call leg #1 and sends a Re-INVITE to UA2 on call leg#2. At the same time UA1 sends a re-invite on call leg#2 to UA2. These are part of session refresh being triggered using re-invites. UA1 UA2 -- INVITE w/ SDP (call leg#1)--- > <-- INVITE w/ SDP (call leg#2)--- -- INVITE w/ SDP (call leg#2)--- > <--491 request pending (call leg#2)--- -- 100 trying(call leg#2)--- > -- 491 request pending(call leg#2)--- > -- ACK(call leg#2)--- > <-- ACK (call leg #2)--- Question is - When a re-invite and 491 pending cross over happens on a dialog (call dialog #2), how do both the UA resolve this. What retry timers are used to resolve this and is there a draft available that addresses this issue? Thanks in advance Dushyant ------------------------------------------------------------------------ ------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Please do not print this email unless it is absolutely necessary. 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 Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors