Hi, I seem to remember reading about this problem before, but couldn't find any pointers by searching...
On the following setup with Openser 1.1:
UA -> Openser/Mediaproxy -> PSTN-Gateway
most calls pass just fine and cancel fine, but some don't stop properly. If the UA cancels the call the cancel goes:
gateway ip= 1.2.3.204 proxy ip= 1.2.3.201 ua ip = 81.1.2.223
U 81.1.2.223:5071 -> 1.2.3.201:5060 CANCEL sip:0475711111@sipc.example.com SIP/2.0. Via: SIP/2.0/UDP 192.168.1.11:5071;branch=z9hG4bK-2f6ae216. From: 002 sip:101211111@sipc.example.com;tag=a27b4fe18ca60f4ao0. To: sip:0475711111@sipc.example.com.
U 1.2.3.201:5060 -> 127.0.0.1:5060 CANCEL sip:0475711111@sipc.example.com SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=a27b4fe18ca60f4ao0. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK7f9f.b68d8185.0. Via: SIP/2.0/UDP 192.168.1.11:5071;received=81.1.2.223;branch=z9hG4bK-2f6ae216. From: 002 sip:101211111@sipc.example.com;tag=a27b4fe18ca60f4ao0. To: sip:0475711111@sipc.example.com.
I 127.0.0.1 -> 1.2.3.201 3:3 ....E..o..@.@...Y............[h.CANCEL sip:0475711111@sipc.example.com SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=a27b4fe18ca60f4ao0. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK7f9f.b68d8185.0. Via: SIP/2.0/UDP 192.168.1.11:5071;received=81.1.2.223;branch=z9hG4bK-2f6ae216. From: 002 sip:101211111@sipc.example.com;tag=a27b4fe18ca60f4ao0. To: sip:0475711111@sipc.example.com.
And then it keeps looping between 127.0.0.1 and 1.2.3.201. For some reason openser sends the CANCEL to the loopback interface instead of on to the gateway. Is this a recognizable problem or should I post a full trace and config file?
Thanks for looking,
Richard.
On Thu, 15 Nov 2007 21:18:38 +0100, Richard Bennett richard.bennett@skynet.be wrote:
Hi, I seem to remember reading about this problem before, but couldn't find any pointers by searching...
On the following setup with Openser 1.1:
UA -> Openser/Mediaproxy -> PSTN-Gateway
After further investigation it seems this problem is happening with SIP to SIP calls as well. Basically if I let the UA ring about 10 times and then cancel the call the proxy will send the CANCEL to 127.0.0.1 instead of to the other party. I see some old bits of my config are commented out:
modparam("tm", "fr_inv_timer", 27) #modparam("tm", "fr_inv_timer_avp", "inv_timeout")
and in the route block; # avp_write("i:45", "inv_timeout");
So obviously at some point I stopped setting the inv_timeout in the route block. If I increase modparam("tm", "fr_inv_timer", 27) to modparam("tm", "fr_inv_timer", 120) then the problem seems to be a lot less... Does setting fr_inv_timer to 120 globally potentially cause other problems besides using more server resources?
Thanks
Richard
El Friday 16 November 2007 16:18:14 Richard Bennett escribió:
modparam("tm", "fr_inv_timer", 27) #modparam("tm", "fr_inv_timer_avp", "inv_timeout")
and in the route block; # avp_write("i:45", "inv_timeout");
So obviously at some point I stopped setting the inv_timeout in the route block. If I increase modparam("tm", "fr_inv_timer", 27) to modparam("tm", "fr_inv_timer", 120) then the problem seems to be a lot less... Does setting fr_inv_timer to 120 globally potentially cause other problems besides using more server resources?
Note that if you set: modparam("tm", "fr_inv_timer", 27) but don't set: modparam("tm", "noisy_ctimer", 1) <-- by default is 0 !!!
then after 27 seconds ringing TM module forgets the transaction, so it will not understand that CANCEL (and maybe because that the CANCEL is sent wronly by localhost).
But if you set: modparam("tm", "noisy_ctimer", 1) then after 27 seconds ringing OpenSer TM module will generate a CANCEL and end the transaction properly.
On Fri, 16 Nov 2007 16:59:42 +0100, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
Note that if you set: modparam("tm", "fr_inv_timer", 27) but don't set: modparam("tm", "noisy_ctimer", 1) <-- by default is 0 !!!
then after 27 seconds ringing TM module forgets the transaction, so it will not understand that CANCEL (and maybe because that the CANCEL is sent wronly by localhost).
But if you set: modparam("tm", "noisy_ctimer", 1) then after 27 seconds ringing OpenSer TM module will generate a CANCEL and end the transaction properly.
Thanks, Great info, that solved the problem, and explained why expired transactions were going to 127.0.0.1. tm has so much stuff... must check what else is helpful...
Thanks,
Richard.
-
Iñaki Baz Castillo -
Richard Bennett