15 Nov
2007
15 Nov
'07
11:18 p.m.
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.
16 Nov
16 Nov
6:18 p.m.
On Thu, 15 Nov 2007 21:18:38 +0100, Richard Bennett
<richard.bennett(a)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
6:59 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
8 p.m.
On Fri, 16 Nov 2007 16:59:42 +0100, Iñaki Baz Castillo <ibc(a)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.
6203
days inactive
6204
days old
3 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
Richard Bennett