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

[Nuno Ribeiro]

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.

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>
> >              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/>
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > Serusers at lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> >
> >
> >
> > --
> > Nuno Ribeiro
>



-- 
Nuno Ribeiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080310/6c65eb10/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pstn_mark.rar
Type: application/rar
Size: 4486 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080310/6c65eb10/attachment.rar>