Hi all,<br><br>I'm facing a problem with "early CANCEL's" such the one described in this thread. The scenario is the following one:<br><br>A PSTN call to a SIP phone. When the PSTN decides to cancel the call only a right after initiating, the PSTN will send the CANCEL message to the SER but this is discarded and not forwarded to the correct path to the SIP Phone. So what happens is that we have a ghost call.... The PSTN has already canceled the call but the SIP phone continues to ring.<br>
<br>The code that I have in the SER script is really simple and the behavior to a CANCEL is the same as to a INVITE:<br><br>if(subst_uri('/^sip:(\+[0-9]+)@<a href="http://192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){">192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){</a><br>
record_route();<br> loose_route();<br> t_relay_to_udp("<a href="http://192.168.20.5">192.168.20.5</a>", "5060");<br> break;<br>}<br>In the log file I see that:<br>
RFC3261 transaction matching failed<br>t_lookup_request: no transaction found<br>e2e_cancel: e2e cancel proceeding <br><br><br>During this thread I saw that a CANCEL handling tm option was decided to be created. Maybe this option can help me to solve the ghost call issue. How can I change the default behavior ? this feature is available from which SER release ?<br>
<br>Any idea how I can solve this isse?<br><br>Thanks in advance.<br> <span class="nfakPe"></span><br>Best Regards<br><br><div class="gmail_quote">On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <<a href="mailto:jiri@iptel.org">jiri@iptel.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">At 15:58 26/02/2007, Klaus Darilion wrote:<br>
>FYI: This is the pragmatic approach how openser users handle the problem:<br>
><br>
>1. drop the CANCEL if there is no corresponding INVITE transaction. The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)<br>
><br>
>if ( is_method("CANCEL") && !t_check_trans() ) {<br>
> # CANCEL without matching INVITE transaction, ignore!<br>
> # May happen if the INVITE is slower than the CANCEL.<br>
> # Ignore the CANCEL, as the client will retransmit it, and maybe<br>
> # the INVITE transaction is already created for the next CANCEL<br>
> xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n");<br>
> exit;<br>
>}<br>
<br>
</div>which does not appear really reboot-safe to me. What it can lead to that ser reboot<br>
affects pending calls in that cancels are never forwarded and ringing phones will<br>
never stop ringing -- not very pleasant indeed, is it.<br>
<div class="Ih2E3d"><br>
-jiri<br>
<br>
<br>
<br>
--<br>
Jiri Kuthan <a href="http://iptel.org/%7Ejiri/" target="_blank">http://iptel.org/~jiri/</a><br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">Serusers mailing list<br>
<a href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a><br>
<a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank">http://lists.iptel.org/mailman/listinfo/serusers</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nuno Ribeiro