10 Mar
2008
10 Mar
'08
2:14 p.m.
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(a)iptel.org>
wrote:
On Mar 06, 2008 at 17:45, Nuno Ribeiro
<nribeiro82(a)gmail.com> wrote:
--
Nuno Ribeiro
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Nuno Ribeiro