<HTML dir=ltr><HEAD><TITLE>Re: [OpenSIPS-Users] Opensips should reply "SIP/2.0 200 canceling" to CANCEL after forwarding ? or wait after reply</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6001.18148" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText72079 dir=ltr>
<DIV dir=ltr><FONT face="Courier New" color=#000000 size=2>Hi thanks for this feed back, unfortunatly I do nto have a full trace but I am using sip_trace data from database.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>This is waht I from on this call-id, it seems like an isolated case, but I am wandering where is the "487" triggered</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>88.88.88.88(UA) --> 10.10.10.1(opensips) --> 10.2.2.22(UA)</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>I am handling CANCEL like this, could t_relay() trigger this call ?</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2> ####---> Handling CANCEL<BR> if ( is_method("CANCEL") ) {<BR> if ( t_check_trans() ){<BR> t_relay();<BR> }<BR> exit;<BR> }<BR></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>+---------------------+--------+--------+----------------------+----------------------+----------------+<BR>| time_stamp | method | status | fromip | toip | fromtag |<BR>+---------------------+--------+--------+----------------------+----------------------+----------------+<BR>| 2010-05-26 17:52:52 | INVITE | | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:52 | INVITE | | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:53 | INVITE | | udp:10.10.10.1:5060 | udp:10.2.2.22:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | CANCEL | | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | INVITE | 100 | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | CANCEL | 200 | udp:10.10.10.1:5060 | udp:88.88.88.88:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | | 100 | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | INVITE | | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | INVITE | 200 | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | CANCEL | | udp:10.10.10.1:5060 | udp:10.2.2.22:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | INVITE | 487 | udp:10.10.10.1:5060 | udp:88.88.88.88:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | | 200 | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:52:59 | INVITE | 200 | udp:10.10.10.1:5060 | udp:88.88.88.88:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:53:11 | ACK | | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:53:27 | INVITE | 200 | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 17:53:27 | | 200 | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | SDhbtm701-9270 | <BR>| 2010-05-26 18:13:19 | BYE | | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | 1190677408 | <BR>| 2010-05-26 18:13:20 | BYE | | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | 1190677408 | <BR>| 2010-05-26 18:13:20 | BYE | | udp:10.10.10.1:5060 | udp:88.88.88.88:5060 | 1190677408 | <BR>| 2010-05-26 18:13:40 | BYE | 481 | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | 1190677408 | <BR>| 2010-05-26 18:13:40 | | 481 | udp:88.88.88.88:5060 | udp:10.10.10.1:5060 | 1190677408 | <BR>| 2010-05-26 18:13:40 | BYE | | udp:10.2.2.22:5060 | udp:10.10.10.1:5060 | 1190677408 | <BR>| 2010-05-26 18:13:40 | BYE | 481 | udp:10.10.10.1:5060 | udp:10.2.2.22:5060 | 1190677408 | <BR>+---------------------+--------+--------+----------------------+----------------------+----------------+</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV></DIV>
<DIV dir=ltr><BR><FONT face="Courier New">
<HR tabIndex=-1>
</FONT><FONT face="Courier New"><FONT size=2><B>From:</B> Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]<BR><B>Sent:</B> Mon 21/06/2010 5:09 PM<BR><B>To:</B> OpenSIPS users mailling list<BR><B>Cc:</B> Julien Chavanton<BR><B>Subject:</B> Re: [OpenSIPS-Users] Opensips should reply "SIP/2.0 200 canceling" to CANCEL after forwarding ? or wait after reply<BR></FONT><BR></FONT></DIV>
<DIV>
<P><FONT face="Courier New" size=2>Hi Julien,<BR><BR>I doubt opensips generates a 487 Request terminated for an INVITE when<BR>the CANCEL is passing through - the 497 is end to end, not hop by hop<BR>(as the CANCEL), So, the 487 is generated by callee and opensips simply<BR>relays it back.<BR><BR>Regards,<BR>Bogdan<BR><BR>Julien Chavanton wrote:<BR>> <BR>> Hi, regarding handling of CANCEL request,<BR>> <BR>> Please correct me if I am wrong,<BR>> <BR>> I have glare condition on how Opensips handled Cancel requests.<BR>> The problem is taht Opensips respond "487 Request terminated" strait<BR>> after forwarding the CANCEL but it does not know if the targe UA will<BR>> accept it.<BR>> <BR>> I think it should wait after the target UA to reply before, as this<BR>> can create out of sync situation if there is a problem with the target.<BR>> in this senario the "200 OK" is received at the same time as the<BR>> CANCEL is sent, in this case the target UA as the right to ignore the<BR>> CANCEL because it as generated a final response.<BR>> <BR>> <BR>> UA -----> CANCEL ------------------------> osips<BR>> UA <------ SIP/2.0 200 canceling --------> osips<BR>> osips <--- 200 OK <-- UA<BR>> osips ---> CANCEL --> UA<BR>> UA <---- SIP/2.0 487 Request Terminated -> osips<BR>> <BR><BR>--<BR>Bogdan-Andrei Iancu<BR>OpenSIPS Bootcamp<BR>20 - 24 September 2010, Frankfurt, Germany<BR>www.voice-system.ro<BR><BR></FONT></P></DIV></BODY></HTML>