Hi!
Does anyone of you know how to stop the timeout timer manually?
Thanks!
Sebastian
Sebastian Kühner wrote:
Does anyone of you know how to stop the timeout timer manually?
I really think you're searching at the wrong place to solve your issue. Please post an ngrep log (including call legs to the UAC and to the Gateway) of such a dialog where the cancel doesn't stop the processing.
Andy
Hi!
I'm sending my INVITEs to a gateway that doesn't exist (to simulate a dead gateway).
Here's an ngrep of the communication, I hope you find something (thank you very much):
U 2005/08/19 09:45:43.749962 xxx.xxx.xxx.181:1024 -> xxx.xxx.xxx.234:5060 INVITE sip:00542619999999@pbx.test.com:5060 SIP/2.0. Content-Length: 268. Contact: sip:44441@xxx.xxx.xxx.181:1024. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Content-Type: application/sdp. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. Max-Forwards: 70. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDP xxx.xxx.xxx.181:1024;rport;branch=z9hG4bKc0a801650131c9b14305d51d00002639000 000b4. User-Agent: SJLabs-SJphone/1.30.252. .
U 2005/08/19 09:45:44.098638 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.181:1024 SIP/2.0 100 trying -- your call is important to us. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDP xxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b14305d51d000026 39000000b4. Server: Sip EXpress router (0.9.3 (i386/linux)). Content-Length: 0. Warning: 392 xxx.xxx.xxx.234:5060 "Noisy feedback tells: pid=31992req_src_ip=xxx.xxx.xxx.181 req_src_port=1024 in_uri=sip:00542619999999@pbx.test.com:5060 out_uri=sip:019302254261xxxxx@xxx.xxx.xxx.100:5060 via_cnt==1". .
U 2005/08/19 09:45:44.099306 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.100:5060 INVITE sip:019302254261xxxxx@xxx.xxx.xxx.100:5060 SIP/2.0. Record-Route: sip:xxx.xxx.xxx.234;ftag=257139028539;lr=on. Content-Length: 268. Contact: sip:44441@xxx.xxx.xxx.234:5060. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Content-Type: application/sdp. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. Max-Forwards: 16. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDP xxx.xxx.xxx.234:5060;branch=z9hG4bKe394.2ef01ad1.0. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b1430 5d51d00002639000000b4. User-Agent: SJLabs-SJphone/1.30.252. .
U 2005/08/19 09:45:44.546725 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.100:5060 INVITE sip:019302254261xxxxx@xxx.xxx.xxx.100:5060 SIP/2.0. Record-Route: sip:xxx.xxx.xxx.234;ftag=257139028539;lr=on. Content-Length: 268. Contact: sip:44441@xxx.xxx.xxx.234:5060. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Content-Type: application/sdp. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. Max-Forwards: 16. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDP xxx.xxx.xxx.234:5060;branch=z9hG4bKe394.2ef01ad1.0. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b1430 5d51d00002639000000b4. User-Agent: SJLabs-SJphone/1.30.252. .
U 2005/08/19 09:45:46.550686 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.100:5060 INVITE sip:019302254261xxxxx@xxx.xxx.xxx.100:5060 SIP/2.0. Record-Route: sip:xxx.xxx.xxx.234;ftag=257139028539;lr=on. Content-Length: 268. Contact: sip:44441@xxx.xxx.xxx.234:5060. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Content-Type: application/sdp. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. Max-Forwards: 16. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDP xxx.xxx.xxx.234:5060;branch=z9hG4bKe394.2ef01ad1.0. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b1430 5d51d00002639000000b4. User-Agent: SJLabs-SJphone/1.30.252. .
U 2005/08/19 09:45:46.747447 xxx.xxx.xxx.181:1024 -> xxx.xxx.xxx.234:5060 CANCEL sip:00542619999999@pbx.test.com:5060 SIP/2.0. Content-Length: 0. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Max-Forwards: 70. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 CANCEL. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport;branch=z9hG4bKc0a801650131c9b14305d51d 00002639000000b4. User-Agent: SJLabs-SJphone/1.30.252. .
U 2005/08/19 09:45:46.997466 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.181:1024 SIP/2.0 200 ok -- no more pending branches. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 CANCEL. To:sip:00542619999999@pbx.test.com:5060;tag=2fb8a6135db5d855a493c61ec96336 75-1e47. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b1430 5d51d00002639000000b4. Server: Sip EXpress router (0.9.3 (i386/linux)). Content-Length: 0. Warning: 392 xxx.xxx.xxx.234:5060 "Noisy feedback tells: pid=31972 req_src_ip=xxx.xxx.xxx.181 req_src_port=1024 in_uri=sip:00542619999999@pbx.test.com:5060 out_uri=sip:00542619999999@pbx.test.com:5060 via_cnt==1". .
U 2005/08/19 09:45:50.556748 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.100:5060 INVITE sip:019302254261xxxxx@xxx.xxx.xxx.100:5060 SIP/2.0. Record-Route: sip:xxx.xxx.xxx.234;ftag=257139028539;lr=on. Content-Length: 268. Contact: sip:44441@xxx.xxx.xxx.234:5060. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Content-Type: application/sdp. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. Max-Forwards: 16. To: sip:00542619999999@pbx.test.com:5060. Via: SIP/2.0/UDP xxx.xxx.xxx.234:5060;branch=z9hG4bKe394.2ef01ad1.0. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b1430 5d51d00002639000000b4. User-Agent: SJLabs-SJphone/1.30.252. .
U 2005/08/19 09:45:51.559405 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.181:1024 SIP/2.0 408 Request Timeout. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. CSeq: 1 INVITE. To:sip:00542619999999@pbx.test.com:5060;tag=2fb8a6135db5d855a493c61ec96336 75-1e47. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;rport=1024;branch=z9hG4bKc0a801650131c9b1430 5d51d00002639000000b4. Server: Sip EXpress router (0.9.3 (i386/linux)). Content-Length: 0. Warning: 392 xxx.xxx.xxx.234:5060 "Noisy feedback tells: pid=32068 req_src_ip=xxx.xxx.xxx.181 req_src_port=1024 in_uri=sip:00542619999999@pbx.test.com:5060 out_uri=sip:019302254261xxxxx@xxx.xxx.xxx.100:5060 via_cnt==0". .
U 2005/08/19 09:45:51.563326 xxx.xxx.xxx.181:1024 -> xxx.xxx.xxx.234:5060 ACK sip:00542619999999@pbx.test.com:5060 SIP/2.0. Content-Length: 0. Call-ID: 2E863532-7483-4585-B9FA-C6EC3340203B@192.168.1.101. Max-Forwards: 70. CSeq: 1 ACK. From: "Administrator"sip:44441@pbx.test.com:5060;tag=257139028539. To:sip:00542619999999@pbx.test.com:5060;tag=2fb8a6135db5d855a493c61ec96336 75-1e47. Via: SIP/2.0/UDPxxx.xxx.xxx.181:1024;branch=z9hG4bKc0a801650131c9b14305d51d000026 39000000b4. .
----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Sebastian Kühner" skuehner@veraza.com Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 10:22 AM Subject: Re: [Serusers] Timeout
Sebastian Kühner wrote:
Does anyone of you know how to stop the timeout timer manually?
I really think you're searching at the wrong place to solve your issue. Please post an ngrep log (including call legs to the UAC and to the Gateway) of such a dialog where the cancel doesn't stop the processing.
Andy
Sebastian Kühner wrote:
U 2005/08/19 09:45:46.997466 xxx.xxx.xxx.234:5060 -> xxx.xxx.xxx.181:1024 SIP/2.0 200 ok -- no more pending branches.
Hm... this one is generated in e2e_cancel(...) in modules/tm/t_fwd.c:363 but I can't see anything there which stops fr_timer for the branch (but I'm not familiar with the tm-code). cancel_bm seems to be zero, so not very much is done there... Maybe someone of the core developers should have a look?
Andy
Hi!
Thanks for your answer.
What would help me is if I would be able to give some "variable" to the failure_route.
Something like that:
if (method == "CANCEL") { "setvariable"(test); };
setflag and avpops doesn't work. The flags/variables are deleted befor reaching my failure route.
Any idea?
Thanks!
Sebastian
----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Sebastian Kühner" skuehner@veraza.com; "Jan Janak" jan@iptel.org Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 11:47 AM Subject: Re: [Serusers] Timeout
Sebastian Kühner wrote:
U 2005/08/19 09:45:46.997466 xxx.xxx.xxx.234:5060 ->
xxx.xxx.xxx.181:1024
SIP/2.0 200 ok -- no more pending branches.
Hm... this one is generated in e2e_cancel(...) in modules/tm/t_fwd.c:363 but I can't see anything there which stops fr_timer for the branch (but I'm not familiar with the tm-code). cancel_bm seems to be zero, so not very much is done there... Maybe someone of the core developers should have a look?
Andy
AVPOPS should work - that's probably the most used use-case for AVPOPS.
klaus
Sebastian Kühner wrote:
Hi!
Thanks for your answer.
What would help me is if I would be able to give some "variable" to the failure_route.
Something like that:
if (method == "CANCEL") { "setvariable"(test); };
setflag and avpops doesn't work. The flags/variables are deleted befor reaching my failure route.
Any idea?
Thanks!
Sebastian
----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Sebastian Kühner" skuehner@veraza.com; "Jan Janak" jan@iptel.org Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 11:47 AM Subject: Re: [Serusers] Timeout
Sebastian Kühner wrote:
U 2005/08/19 09:45:46.997466 xxx.xxx.xxx.234:5060 ->
xxx.xxx.xxx.181:1024
SIP/2.0 200 ok -- no more pending branches.
Hm... this one is generated in e2e_cancel(...) in modules/tm/t_fwd.c:363 but I can't see anything there which stops fr_timer for the branch (but I'm not familiar with the tm-code). cancel_bm seems to be zero, so not very much is done there... Maybe someone of the core developers should have a look?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
No, it doesn't. Like all the things that I'm trying to solve my problem...
if (method == "CANCEL") { reset_gw(); avp_write("s:cancel", "s:cancel"); log(1, "-CANCEL PSTN-\n"); };
if (avp_check("s:cancel","eq/s:cancel/g")) { log(1, "YES - after!!!!\n"); };
[...]
failure_route[2] { if (avp_check("s:cancel","eq/s:cancel/g")) { log(1, "YES - failover!!!!\n"); };
if (method=="INVITE" && t_check_status("408|500|503") && !avp_check("s:cancel","eq/s:cancel/g")) { log (1, "next gateway...\n"); [...]
Logging shows:
1.) YES - after --> so the variable is saved 2.) next gatway...
But it never shows YES - failover, so the variable doesn't reach the failure_route
Any idea? I seem to be the only person that has that problem :-((( ser seems to be so good... and now that... I'm stucked!!!
----- Original Message ----- From: "Klaus Darilion" klaus.mailinglists@pernau.at To: "Sebastian Kühner" skuehner@veraza.com Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 12:33 PM Subject: Re: [Serusers] Timeout
AVPOPS should work - that's probably the most used use-case for AVPOPS.
klaus
Sebastian Kühner wrote:
Hi!
Thanks for your answer.
What would help me is if I would be able to give some "variable" to the failure_route.
Something like that:
if (method == "CANCEL") { "setvariable"(test); };
setflag and avpops doesn't work. The flags/variables are deleted befor reaching my failure route.
Any idea?
Thanks!
Sebastian
----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Sebastian Kühner" skuehner@veraza.com; "Jan Janak"
Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 11:47 AM Subject: Re: [Serusers] Timeout
Sebastian Kühner wrote:
U 2005/08/19 09:45:46.997466 xxx.xxx.xxx.234:5060 ->
xxx.xxx.xxx.181:1024
SIP/2.0 200 ok -- no more pending branches.
Hm... this one is generated in e2e_cancel(...) in modules/tm/t_fwd.c:363 but I can't see anything there which stops fr_timer for the branch (but I'm not familiar with the tm-code). cancel_bm seems to be zero, so not very much is done there... Maybe someone of the core developers should have a look?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
avps are transaction specific. i don't think that CANCEL is at that point associated with the failure_route (INVITE).
----- Original Message ----- From: "Klaus Darilion" klaus.mailinglists@pernau.at To: "Sebastian Kühner" skuehner@veraza.com Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 12:33 PM Subject: Re: [Serusers] Timeout
AVPOPS should work - that's probably the most used use-case for AVPOPS.
klaus
Sebastian Kühner wrote:
Hi!
Thanks for your answer.
What would help me is if I would be able to give some "variable" to the failure_route.
Something like that:
if (method == "CANCEL") { "setvariable"(test); };
setflag and avpops doesn't work. The flags/variables are deleted befor reaching my failure route.
Any idea?
Thanks!
Sebastian
----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Sebastian Kühner" skuehner@veraza.com; "Jan Janak"
Cc: serusers@lists.iptel.org Sent: Monday, August 22, 2005 11:47 AM Subject: Re: [Serusers] Timeout
Sebastian Kühner wrote:
U 2005/08/19 09:45:46.997466 xxx.xxx.xxx.234:5060 ->
xxx.xxx.xxx.181:1024
SIP/2.0 200 ok -- no more pending branches.
Hm... this one is generated in e2e_cancel(...) in modules/tm/t_fwd.c:363 but I can't see anything there which stops fr_timer for the branch (but I'm not familiar with the tm-code). cancel_bm seems to be zero, so not very much is done there... Maybe someone of the core developers should have a look?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Andreas Granig -
Klaus Darilion -
Sebastian Kühner