[Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

Nuno Ribeiro nribeiro82 at gmail.com
Wed Mar 12 10:48:41 CET 2008


I will follow your indications and after that I will give you feedback about
this solution.
Thanks,


On Mon, Mar 10, 2008 at 4:14 PM, Andrei Pelinescu-Onciul <andrei at iptel.org>
wrote:

> On Mar 10, 2008 at 12:14, Nuno Ribeiro <nribeiro82 at gmail.com> wrote:
> > Hi Andrei,
> >
> > Thanks for your availability to help me...
> > 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).
> > I send in attachment the wireshark log where you can the network traces
> that
> > you referred.
>
> No, in fact the CANCEL matches and terminates the transaction
> (you go INVITE, 100 Trying, INVITE forwarded, CANCEL, 487 to the orig.
> INVITE due to the CANCEL and the 200 to the CANCEL).
> The problem is when the CANCEL arrives the INVITE transaction has not
> received any reply yet (if you look in the dump you'll see an 100 trying
>  from .5 long after the CANCEL is received). In ser in this case (CANCEL
>  received and no response yet on a branch)  the branch is dropped
>  immediately and a "fake" 487 is sent back (the ideea is that most
>  likely the UA to which the INVITE was forwarded is dead and it saves a
>  lot of resources if we quickly kill the transaction -- unfortunately this
>  backfires in your case). The CANCEL is also not forwarded downstream (the
>  rfc says that CANCEL should be sent only on replied branches).
>
> So to make a long story short, upgrade to the latest cvs version and set
>  modparam("tm", "cancel_b_method", 1). This will keep retransmitting
>  the INVITE if no reply was received, even after the CANCEL arrives and
>  it will avoid all the above problems (see modules/tm/README |grep
>  cancel_b_method for a more detailed description).
> If you still have problem, drop me another mail. I'm very interested if
> the cancel fix works properly, not only in my testbed. I'm starting to
> think
> that making this the default behaviour might be a good ideea (since it
> seems that it causes problems quite frequently). It might even become a
>  candidate for a backport to stable.
>
>
> Andrei
>
> >
> > PS: the first message was rejected by the list as the message was to
> big....
> >
> > Best Regards,
> >
> > On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <
> andrei at iptel.org>
> > wrote:
> >
> > > On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82 at gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > I'm facing a problem  with "early CANCEL's" such the one described
> in
> > > this
> > > > thread. The scenario is the following  one:
> > > >
> > > > 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.
> > > >
> > > > 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:
> > > >
> > > > if(subst_uri('/^sip:(\+[0-9]+)@
> > > > 192.168.20.69.*user=phone$/sip:\1 at xlab.com/i')){<http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B>
> <http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B>
> > > >              record_route();
> > > >              loose_route();
> > > >              t_relay_to_udp("192.168.20.5", "5060");
> > > >              break;
> > > > }
> > > > In the log file I see that:
> > > > RFC3261 transaction matching failed
> > > > t_lookup_request: no transaction found
> > > > e2e_cancel: e2e cancel proceeding
> > > >
> > > >
> > > > 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 ?
> > >
> > > The option is unmatched_cancel and is present for ser 2.1 (cvs head).
> > > However what this does is select between dropping unmatched cancels,
> > > forwarding them statelessly or statefully.
> > > Older ser versions always forward the cancel statefully, which is what
> > > you want in most cases (including yours).
> > >
> > > It's strage that the cancel doesn't seem to match the invite
> transaction
> > > in your case.
> > > If you would send me some networks dumps with the invite and the
> cancel
> > > I could tell you more.
> > >
> > >
> > > Andrei
> > >
> > >
> > > >
> > > > Any idea how I can solve this isse?
> > > >
> > > > Thanks in advance.
> > > >
> > > > Best Regards
> > > >
> > > > On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <jiri at iptel.org> wrote:
> > > >
> > > > > At 15:58 26/02/2007, Klaus Darilion wrote:
> > > > > >FYI: This is the pragmatic approach how openser users handle the
> > > problem:
> > > > > >
> > > > > >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)
> > > > > >
> > > > > >if ( is_method("CANCEL") && !t_check_trans() ) {
> > > > > >  # CANCEL without matching INVITE transaction, ignore!
> > > > > >  # May happen if the INVITE is slower than the CANCEL.
> > > > > >  # Ignore the CANCEL, as the client will retransmit it, and
> maybe
> > > > > >  # the INVITE transaction is already created for the next CANCEL
> > > > > >  xlog("L_WARN","$ci CANCEL without matching transaction ...
> > > ignore\n");
> > > > > >  exit;
> > > > > >}
> > > > >
> > > > > which does not appear really reboot-safe to me. What it can lead
> to
> > > that
> > > > > ser reboot
> > > > > affects pending calls in that cancels are never forwarded and
> ringing
> > > > > phones will
> > > > > never stop ringing -- not very pleasant indeed, is it.
> > > > >
> > > > > -jiri
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jiri Kuthan            http://iptel.org/~jiri/<http://iptel.org/%7Ejiri/>
> <http://iptel.org/%7Ejiri/><
> > > http://iptel.org/%7Ejiri/>
> > > > >
> > > > > _______________________________________________
> > > > > Serusers mailing list
> > > > > Serusers at lists.iptel.org
> > > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Nuno Ribeiro
> > >
> >
> >
> >
> > --
> > Nuno Ribeiro
>
>
>


-- 
Nuno Ribeiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080312/ed36f3ea/attachment.htm>


More information about the sr-users mailing list