So finally I ran Wireshark. It confirmed that there is no CANCEL from the caller, yet Kamailio sends CANCEL to the called side. It also shows that Kamailio sends and resends INVITE to several ports and keeps sending them until 200 OK. After that Kamailio sends CANCEL. Is it trying to cancel a parallel branch? The Wireshark files are accessible at ftp://quacka.no-ip.org/pub/ekiga-called-packets-sipfiltered ftp://quacka.no-ip.org/pub/ekiga-caller-packets-sipfiltered
P.S. some packets are segmented, use SIP filtering in Wireshark to display them properly ----- Originálna Správa ----- Od: Damien Sandras Komu: Ekiga mailing list Poslaná: 02.12.2008 13:09 Predmet: Re: [Ekiga-list] \\\"remote user cleared the call\\\" problem > Le mardi 02 dĂŠcembre 2008 Ă 11:19 +0100, Palo S. a ĂŠcrit : > > > > > > A cancel can be sent if you are using forking, ie 2 Ekiga registered > > > with the same account name, from 2 different IP addresses and ports. As > > > soon as one answers, a CANCEL is sent to the other one. > > > > > > Couldn\\\'t it be the case ? > > > > It could be that due to a problem with NAT a private > > IP communicates with the server as well as the public > > IP. I can probably only say after I sniff the > > communication. I will run a sniffer when I have time > > and let you know if I find something interesting. It > > is also interesting that with Ekiga 2.0.12 (on called > > side) it behaves differently - I have not had a look > > at d4 yet but it looked like caller (thought that) > > estabilished a SIP connection but called side not > > (it continued to ring on the called side, even after > > cancelling the call on the caller side). > > > > In any case, it worked fine with the previous server, > > so there must be a way to either fix or at least > > workaround the problem on the code level (either server > > or maybe also client) which would be nice at least because > > of ordinary users that do not know/wish to play around > > with port forwarding (all ports forwarding was > > originally enabled by the provider in this case, not by > > the user...) > > > > If only I understood what really happens... Unfortunately, it is not the > case :( > -- > _ Damien Sandras > (o- > //\\ Ekiga Softphone : http://www.ekiga.org/ > v_/_ Be IP : http://www.beip.be/ > FOSDEM : http://www.fosdem.org/ > SIP Phone : sip:[EMAIL PROTECTED] > > > _______________________________________________ > ekiga-list mailing list > ekiga-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list __________ Najoriginalnejsie technologicke hracky - http://pocitace.sme.sk/ _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
