[SR-Users] CANCEL before INVITE

[Andrei Pelinescu-Onciul]

On Jul 06, 2010 at 14:06, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Obiously the device is buggy.
> 
> But there is also on strange thing at Kamailio: it retransmits the
> CANCEL although it has already received 481 response on the CANCEL
> request.

The first 481 stops the CANCEL retransmissions, however each additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the 481,
it's the "response" to the 180...

Andrei
> 
> regards
> klaus
> 
> Am 06.07.2010 00:06, schrieb David:
> >Hello,
> >
> >Here are the corrected attachments, I sent the email from Window's
> >wordpad which set it to RTF by default.
> >
> >Here are proper txt logs.
> >
> >David
> >
> >On 2010-07-05 17:47, David wrote:
> >>Hello,
> >>
> >>I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
> >>receives a 100 Trying, as mentioned in RFC3261 section 9.
> >>
> >>I stripped down the config file to the bare minimum so that it is
> >>easier to debug ( see attached kamailio.cfg )
> >>
> >>I have included my config file as well as a packet sniff that was done
> >>with ngrep.
> >>
> >>As you can see, the packets are in the correct order, but the Linksys
> >>is crying "Call leg Transaction does not exist" despite the fact that
> >>the CANCEL has ( as far as I can tell ) responded according to
> >>RFC3261. I compared the headers that are required by RFC ( The
> >>Request-URI, Call-ID, To, the numeric part of CSeq, and From header
> >>fields in the CANCEL request MUST be identical to those in the request
> >>being cancelled, including tags. ) but it still says Call Leg
> >>Transaction does not exist. ( see ngrep-sip-wip-310.log ).
> >>
> >>If I send the CANCEL once the device is ringing, it works fine ( see
> >>sip-trace-good.log ).
> >>
> >>If I send the CANCEL after the 100 Trying but before the 180 Ringing (
> >>which is acceptable according to RFC3261 ), the device returns call
> >>leg incorrect.
> >>
> >>This looks suspiciously like a bug in the WIP310, but I am not sure.
> >>
> >>Can someone please shed some light on my situation?
> >>
> >>Thanks,
> >>
> >>David
> >>
> >>On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
> >>>On Jun 17, 2010 at 16:39, David<kamailio.org at spam.lublink.net>  wrote:
> >>>
> >>>>Hello,
> >>>>
> >>>>I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
> >>>>is answering "100 Trying" to the caller, so the it is ok for the
> >>>>caller to send back a CANCEL request. Trouble is Kamailio forwards
> >>>>the request to the called user even though the called user never
> >>>>sent a provisional response.
> >>>>
> >>>>Since the Kamailio server never received a provisional request, it
> >>>>is therefore incorrect for it to forward the CANCEL request to the
> >>>>called user. ( correct me if I am wrong ).
> >>>>
> >>>Try 3.0 (kamailio or sip-router). You can control how unreplied branches
> >>>are canceled, see
> >>>http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#cancel_b_method
> >>>
> >>>
> >>>Andrei
> >>>
> >>
> >>
> >>_______________________________________________
> >>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >>sr-users at lists.sip-router.org
> >>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >
> >
> >
> >
> >_______________________________________________
> >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >sr-users at lists.sip-router.org
> >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> 
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users