I will follow your indications and after that I will give you feedback about this solution.<br>Thanks,<br><br><br><div class="gmail_quote">On Mon, Mar 10, 2008 at 4:14 PM, 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 class="Ih2E3d">On Mar 10, 2008 at 12:14, Nuno Ribeiro <<a href="mailto:nribeiro82@gmail.com">nribeiro82@gmail.com</a>> wrote:<br>
> 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<br>
> few moments after the INVITE. I think that the transaction from the INVITE<br>
> is not yet completely created so when the CANCEL is received it doesn't<br>
> match any transaction (t_lookup_request: no transaction found).<br>
> I send in attachment the wireshark log where you can the network traces that<br>
> you referred.<br>
<br>
</div>No, in fact the CANCEL matches and terminates the transaction<br>
(you go INVITE, 100 Trying, INVITE forwarded, CANCEL, 487 to the orig.<br>
INVITE due to the CANCEL and the 200 to the CANCEL).<br>
The problem is when the CANCEL arrives the INVITE transaction has not<br>
received any reply yet (if you look in the dump you'll see an 100 trying<br>
from .5 long after the CANCEL is received). In ser in this case (CANCEL<br>
received and no response yet on a branch) the branch is dropped<br>
immediately and a "fake" 487 is sent back (the ideea is that most<br>
likely the UA to which the INVITE was forwarded is dead and it saves a<br>
lot of resources if we quickly kill the transaction -- unfortunately this<br>
backfires in your case). The CANCEL is also not forwarded downstream (the<br>
rfc says that CANCEL should be sent only on replied branches).<br>
<br>
So to make a long story short, upgrade to the latest cvs version and set<br>
modparam("tm", "cancel_b_method", 1). This will keep retransmitting<br>
the INVITE if no reply was received, even after the CANCEL arrives and<br>
it will avoid all the above problems (see modules/tm/README |grep<br>
cancel_b_method for a more detailed description).<br>
If you still have problem, drop me another mail. I'm very interested if<br>
the cancel fix works properly, not only in my testbed. I'm starting to think<br>
that making this the default behaviour might be a good ideea (since it<br>
seems that it causes problems quite frequently). It might even become a<br>
candidate for a backport to stable.<br>
<br>
<br>
Andrei<br>
<div class="Ih2E3d"><br>
><br>
> PS: the first message was rejected by the list as the message was to big....<br>
><br>
> Best Regards,<br>
><br>
> On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <<a href="mailto:andrei@iptel.org">andrei@iptel.org</a>><br>
> wrote:<br>
><br>
> > 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<br>
> > 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<br>
> > only a<br>
> > > right after initiating, the PSTN will send the CANCEL message to the SER<br>
> > but<br>
> > > this is discarded and not forwarded to the correct path to the SIP<br>
> > Phone. So<br>
> > > what happens is that we have a ghost call.... The PSTN has already<br>
> > 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<br>
> > to<br>
> > > a CANCEL is the same as to a INVITE:<br>
> > ><br>
> > > if(subst_uri('/^sip:(\+[0-9]+)@<br>
</div>> > > <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><<a href="http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B" target="_blank">http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B</a>><br>
<div><div></div><div class="Wj3C7c">> > > 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<br>
> > to be<br>
> > > created. Maybe this option can help me to solve the ghost call issue.<br>
> > How<br>
> > > can I change the default behavior ? this feature is available from<br>
> > which<br>
> > > SER release ?<br>
> ><br>
> > 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>
> ><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<br>
> > problem:<br>
> > > > ><br>
> > > > >1. drop the CANCEL if there is no corresponding INVITE transaction.<br>
> > The<br>
> > > > UAC must retransmit the CANCEL and meanwhile there should be the<br>
> > 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 ...<br>
> > ignore\n");<br>
> > > > > exit;<br>
> > > > >}<br>
> > > ><br>
> > > > which does not appear really reboot-safe to me. What it can lead to<br>
> > 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>
> > > > 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>
> > <a href="http://iptel.org/%7Ejiri/" target="_blank">http://iptel.org/%7Ejiri/</a>><br>
> > > ><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>
> ><br>
><br>
><br>
><br>
> --<br>
> Nuno Ribeiro<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nuno Ribeiro