Re: [SR-Users] CANCEL before INVITE

On Jul 06, 2010 at 14:06, Klaus Darilion<klaus.mailinglists(a)pernau.at> wrote: 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(a)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(a)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(a)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(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users