On Jul 06, 2010 at 16:55, Klaus Darilion <klaus.mailingli...@pernau.at> wrote: > > > Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul: > >On Jul 06, 2010 at 14:06, Klaus Darilion<klaus.mailingli...@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....@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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
