Hi Andrei and all,

Sorry by the late answer. I had other tasks in my hands that were more important than this one.
I have made the migration of the code that you added in that version to my own testbed and it solved the issue.

I think that this solution would be great if you put on the stable version as it solves an issue that In my opinion is view is very important : ghost calls.

Best Regards,

Nuno Ribeiro

On Mon, Mar 10, 2008 at 5:14 PM, Andrei Pelinescu-Onciul <andrei@iptel.org> wrote:
On Mar 10, 2008 at 12:14, Nuno Ribeiro <nribeiro82@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@iptel.org>
> wrote:
>
> > On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82@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@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@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@lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > >
> > >
> > >
> > > --
> > > Nuno Ribeiro
> >
>
>
>
> --
> Nuno Ribeiro





--
Nuno Ribeiro