Hi Andrei,<br><br>Thanks for your availability to help me... <br>Note that this situation only occurs if the CANCEL message is originated a few moments after the INVITE. I think that the transaction from the INVITE is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found).<br>
I send in attachment the wireshark log where you can the network traces that you referred. <br><br>PS: the first message was rejected by the list as the message was to big....<br><br>Best Regards,<br><br><div class="gmail_quote">
On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <<a href="mailto:andrei@iptel.org">andrei@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><div></div><div class="Wj3C7c">On Mar 06, 2008 at 17:45, Nuno Ribeiro <<a href="mailto:nribeiro82@gmail.com">nribeiro82@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I'm facing a problem with "early CANCEL's" such the one described in this<br>
> 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<br>
> right after initiating, the PSTN will send the CANCEL message to the SER but<br>
> this is discarded and not forwarded to the correct path to the SIP Phone. So<br>
> what happens is that we have a ghost call.... The PSTN has already canceled<br>
> 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<br>
> a CANCEL is the same as to a INVITE:<br>
><br>
> if(subst_uri('/^sip:(\+[0-9]+)@<br>
> <a href="http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B" target="_blank">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" target="_blank">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<br>
> created. Maybe this option can help me to solve the ghost call issue. How<br>
> can I change the default behavior ? this feature is available from which<br>
> SER release ?<br>
<br>
</div></div>The option is unmatched_cancel and is present for ser 2.1 (cvs head).<br>
However what this does is select between dropping unmatched cancels,<br>
forwarding them statelessly or statefully.<br>
Older ser versions always forward the cancel statefully, which is what<br>
you want in most cases (including yours).<br>
<br>
It's strage that the cancel doesn't seem to match the invite transaction<br>
in your case.<br>
If you would send me some networks dumps with the invite and the cancel<br>
I could tell you more.<br>
<br>
<br>
Andrei<br>
<div class="Ih2E3d"><br>
<br>
><br>
> Any idea how I can solve this isse?<br>
><br>
> Thanks in advance.<br>
><br>
> Best Regards<br>
><br>
> On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <<a href="mailto:jiri@iptel.org">jiri@iptel.org</a>> wrote:<br>
><br>
> > 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<br>
> > UAC must retransmit the CANCEL and meanwhile there should be the INVITE<br>
> > 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>
> > which does not appear really reboot-safe to me. What it can lead to that<br>
> > ser reboot<br>
> > affects pending calls in that cancels are never forwarded and ringing<br>
> > phones will<br>
> > never stop ringing -- not very pleasant indeed, is it.<br>
> ><br>
> > -jiri<br>
> ><br>
> ><br>
> ><br>
> > --<br>
</div>> > Jiri Kuthan <a href="http://iptel.org/%7Ejiri/" target="_blank">http://iptel.org/~jiri/</a> <<a href="http://iptel.org/%7Ejiri/" target="_blank">http://iptel.org/%7Ejiri/</a>><br>
<div><div></div><div class="Wj3C7c">> ><br>
> > _______________________________________________<br>
> > 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>
> ><br>
><br>
><br>
><br>
> --<br>
> Nuno Ribeiro<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nuno Ribeiro