looks like a dialog matching problem. for further inspection complete SIP dums would be necessary: ngrep port 5060
klaus
Brandon Price wrote:
I find that I am having the same error, although with me it only happens when the sip client is natted and the bye comes from the pstn end. Sample tethereal capture below. I can only assume this has something to do with the nat module which I am currently not using yet but plan to try again to implement today.
48.022862 216.120.255.29 -> 8.11.1.7 SIP/SDP Request: INVITE sip: 15187278584@ser1.manhattan.vtnoc.net, with session description 48.026850 8.11.1.7 -> 216.120.255.29 SIP Status: 100 trying -- your call is important to us 48.027059 8.11.1.7 -> oursippproxy.net SIP/SDP Request: INVITE sip:+15187278584@oursippproxy.net, with session description 48.096933 oursippproxy.net -> 8.11.1.7 SIP Status: 100 Trying 49.299563 oursippproxy.net -> 8.11.1.7 SIP/SDP Status: 183 Session Progress, with session description 49.300461 8.11.1.7 -> 216.120.255.29 SIP/SDP Status: 183 Session Progress, with session description 56.407921 oursippproxy.net -> 8.11.1.7 SIP/SDP Status: 200 OK, with session description 56.409252 8.11.1.7 -> 216.120.255.29 SIP/SDP Status: 200 OK, with session description 56.428281 216.120.255.29 -> 8.11.1.7 SIP Request: ACK sip:oursippproxy.net:5060;transport=udp 56.464595 8.11.1.7 -> oursippproxy.net SIP Request: ACK sip:oursippproxy.net:5060;transport=udp 61.956533 oursippproxy.net -> 8.11.1.7 SIP Request: BYE sip: 15184782411@216.120.255.29:5060 61.957965 8.11.1.7 -> 216.120.255.29 SIP Request: BYE sip: 15184782411@216.120.255.29:5060 61.987385 216.120.255.29 -> 8.11.1.7 SIP Status: 481 Call Leg/ Transaction Does Not Exist 62.017630 8.11.1.7 -> oursippproxy.net SIP Status: 481 Call Leg/ Transaction Does Not Exist
On Oct 11, 2005, at 7:35 AM, Iqbal wrote:
Can you check to see if you have already received a BYE for that call, some phones I had were sending there own Bye's after the GW had
Iqbal
Sam Lee wrote:
Hi all, I would like to know why does my BYE method are always replied with a 'Call Leg/Transaction does not exist' . How do they compare whether the transaction in the BYE method exist or not ? ( tag? ftag ? ) Are there any thing in the config that might cause this kind of problem ? Just want to highlight that all the calls are made in a good condition, everything except when the call is ending.
Please let me know if you dont understand. Regards, Sam
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users