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
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
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
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
I have attached ngrep output of a sample call, edited for readability, and security. Any help will be as always greatly appreciated.
On Oct 11, 2005, at 12:39 PM, Klaus Darilion wrote:
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
Hi Brandon!
At first glance I do not see a problem with the BYE. How does the linksys react? Is the call still ongoing?
Are this Linksysboxes equiped with SIPURA technology? If yes, you could activate logging at the linksys via syslog.
regards klaus
Brandon Price wrote:
216.120.255.29:10060 -> my.sip.proxy.ip:5060
I also want to make sure I include relevant portions of the openser.cfg
{ if (method=="INVITE" && uri =~ "sip:1[0-9]{10}@.*"){ if (is_user_in("From", "ld")){ if (!www_authorize("", "subscriber")){ www_challenge("", "1"); break; if (client_nat_test("4")) { fix_contact(); }; append_rpid_hf(); };
if (search("From: Anonymous.*")){ append_rpid_hf("", ";privacy=full"); };
setflag(1); consume_credentials(); if (lookup("location")) { # if found,lookup aliases and forward there... lookup("aliases"); t_relay(); exit; } else { prefix("+"); rewritehost("our.pstn.gw.ip"); }; }; };
if (method=="BYE" || method=="CANCEL"){ setflag(1); #accounting flag t_relay(); exit; };
On Oct 11, 2005, at 12:39 PM, Klaus Darilion wrote:
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
-
Brandon Price -
Iqbal -
Klaus Darilion -
Sam Lee