<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=idOWAReplyText49697 dir=ltr>
<DIV dir=ltr><FONT face="Courier New" color=#000000 size=2>There was a lot of action taking place in the same second in this SIP glare condition.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" color=#000000 size=2>SIP/2.0 487 Request Terminated<BR>Via: SIP/2.0/UDP 88.88.88.88:5060;branch=z9hG4bKnvvm4u3018h1if0210g1.1<BR>Call-ID: SDhbtm701-2ddaa941b6ca35682061bd51f5f7b29d-agt38s3<BR>From: <sip:7083596365@sipgw14.com;user=phone>;tag=SDhbtm701-9270<BR>To: <sip:7260711@10.10.10.1:5060;user=phone>;tag=db962f7fab4d65668601cd9ff01c7d01-265f<BR>CSeq: 1 INVITE<BR>Server: OpenSIPS (1.5.1-notls (x86_64/linux))<BR>Content-Length: 0</FONT></DIV></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>
<DIV dir=ltr><FONT face="Courier New" size=2>My concern is that Opensips would not take the initiative to confirm a call is terminated sending "487" if it does not have the confirmation from the terminating UA. </FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]<BR><B>Sent:</B> Fri 25/06/2010 8:11 AM<BR><B>To:</B> Julien Chavanton<BR><B>Cc:</B> OpenSIPS users mailling list<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></DIV>
<DIV>
<P><FONT size=2>Hi Julien,<BR><BR>The only case when the 487 is generated by opensips is when a CANCEL is<BR>received for an INVITE branch which did not received yet no reply. In<BR>such a case opensips will inject a 487 reply on that branch to<BR>compensate to lack of reply from the downstream party.<BR><BR>The order of the requests in siptrace is really irrelevant (for < 1s<BR>intervals) as it is strongly affected by the parallel processing in<BR>opensips and by the DB op (to insert the trace).<BR><BR>Could you post the whole 487 reply from DB ? My guess the 487 is a<BR>result of a race between the incoming CANCEL from caller and the first<BR>100 reply from callee.<BR><BR>Regards,<BR>Bogdan<BR><BR>Julien Chavanton wrote:<BR>> Hi thanks for this feed back, unfortunatly I do nto have a full trace<BR>> but I am using sip_trace data from database.<BR>> <BR>> This is waht I from on this call-id, it seems like an isolated case,<BR>> but I am wandering where is the "487" triggered<BR>> <BR>> 88.88.88.88(UA) --> 10.10.10.1(opensips) --> 10.2.2.22(UA)<BR>> <BR>> I am handling CANCEL like this, could t_relay() trigger this call ?<BR>> <BR>> ####---> Handling CANCEL<BR>> if ( is_method("CANCEL") ) {<BR>> if ( t_check_trans() ){<BR>> t_relay();<BR>> }<BR>> exit;<BR>> }<BR>> <BR>> +---------------------+--------+--------+----------------------+----------------------+----------------+<BR>> | time_stamp | method | status | fromip |<BR>> toip | fromtag |<BR>> +---------------------+--------+--------+----------------------+----------------------+----------------+<BR>> | 2010-05-26 17:52:52 | INVITE | | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:52 | INVITE | | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:53 | INVITE | | udp:10.10.10.1:5060 |<BR>> udp:10.2.2.22:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | CANCEL | | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | INVITE | 100 | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | CANCEL | 200 | udp:10.10.10.1:5060 |<BR>> udp:88.88.88.88:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | | 100 | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | INVITE | | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | INVITE | 200 | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | CANCEL | | udp:10.10.10.1:5060 |<BR>> udp:10.2.2.22:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | INVITE | 487 | udp:10.10.10.1:5060 |<BR>> udp:88.88.88.88:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | | 200 | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:52:59 | INVITE | 200 | udp:10.10.10.1:5060 |<BR>> udp:88.88.88.88:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:53:11 | ACK | | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:53:27 | INVITE | 200 | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 17:53:27 | | 200 | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | SDhbtm701-9270 |<BR>> | 2010-05-26 18:13:19 | BYE | | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | 1190677408 |<BR>> | 2010-05-26 18:13:20 | BYE | | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | 1190677408 |<BR>> | 2010-05-26 18:13:20 | BYE | | udp:10.10.10.1:5060 |<BR>> udp:88.88.88.88:5060 | 1190677408 |<BR>> | 2010-05-26 18:13:40 | BYE | 481 | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | 1190677408 |<BR>> | 2010-05-26 18:13:40 | | 481 | udp:88.88.88.88:5060 |<BR>> udp:10.10.10.1:5060 | 1190677408 |<BR>> | 2010-05-26 18:13:40 | BYE | | udp:10.2.2.22:5060 |<BR>> udp:10.10.10.1:5060 | 1190677408 |<BR>> | 2010-05-26 18:13:40 | BYE | 481 | udp:10.10.10.1:5060 |<BR>> udp:10.2.2.22:5060 | 1190677408 |<BR>> +---------------------+--------+--------+----------------------+----------------------+----------------+<BR>> <BR>><BR>> ------------------------------------------------------------------------<BR>> *From:* Bogdan-Andrei Iancu [<A href="mailto:bogdan@voice-system.ro">mailto:bogdan@voice-system.ro</A>]<BR>> *Sent:* Mon 21/06/2010 5:09 PM<BR>> *To:* OpenSIPS users mailling list<BR>> *Cc:* Julien Chavanton<BR>> *Subject:* Re: [OpenSIPS-Users] Opensips should reply "SIP/2.0 200<BR>> canceling" to CANCEL after forwarding ? or wait after reply<BR>><BR>> 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><BR><BR>--<BR>Bogdan-Andrei Iancu<BR>OpenSIPS Bootcamp<BR>20 - 24 September 2010, Frankfurt, Germany<BR>www.voice-system.ro<BR><BR><BR></FONT></P></DIV></BODY></HTML>