[SR-Users] CANCEL before INVITE

Andrei Pelinescu-Onciul andrei at iptel.org
Tue Jul 6 17:04:17 CEST 2010


On Jul 06, 2010 at 16:55, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> 
> 
> Am 06.07.2010 16:36, schrieb 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...
> 
> Cool, nice feature.
> 
> Unfortunately it doesn't help with David's problem, as the phone
> obviously does not see the additional CANCEL - probably the phone's
> transaction layer responds again with 481.

What's strange is that according to the dump it does finally reply with
a 487, but 8s after it sent a 481 to the last CANCEL:

 <- 100
CANCEL ->
 <- 481
 <- 180
CANCEL
 <-481
 [8s]
 <-487

Andrei
> 
> regards
> Klaus
> 
> >
> >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
> 
> _______________________________________________
> 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



More information about the sr-users mailing list