Re: [OpenSER-Users] 200 OK retransmissions on missing ACK can cause subsequent calls to fail
9 May
9 May
9:46 p.m.
New subject: [OpenSER-Users] 200 OK retransmissions on missing ACK can cause subsequent calls to fail
Hi Sean,
So, it is this scenario working ok for you now?
Regards,
Bogdan
Sean O'Donnell wrote:
Hi Bogan:
Ahh, my mistake, I was looking at the TM code from the 1.2.0 release.
I missed the
goto in the more recent releases that fixed the problem.
Thanks!
Sean
---- On Wed, 7 May 2008, Bogdan-Andrei
Iancu (bogdan(a)voice-system.ro) wrote:
Hi Sean,
Yes, t_check() sets T as NULL if no transaction is matched, but the
reply_received() function (that calls t_check), if T was set to NULL
will go to "not_found" label and set T to T_UNDEFINED.
Do you agree on this? if so, we can start working in adding some more
debug logs to see where the problem is.
Regards,
Bogdan
Sean O'Donnell wrote:
Hi all,
I’m using openser as a call distributor/proxy between a soft-switch/SBC and
voicemail platform. I’m seeing a problem with openser in that it is
sometimes
cancels an in-progress call (fr_inv_timer firing)
because it didn’t match
the
200/OK with the call.
After some investigation, I noticed that this was happening after a missing
ACK
on a previous call caused the voicemail platform
to retransmit 200/OK
responses
beyond the TM wt_timer expiration, which in turn
left several openser child
processes (those that received a 200 after wt_timer expiration) in a state
such
that they might not properly match transactions
on subsequent calls.
My setup:
I have openser 1.2.0 operating on a linux box with two network interfaces,
with
one interface (call it the outside interface)
taking incoming calls from
the
soft-switch, and the other (inside) connected to
the VM platform. I have
openser configured to use both interfaces (see config below) and the TM
wt_timer
set to 5 seconds (default). As this is a
voicemail system, all of the call
traffic is inbound from the soft-switch. Given the traffic flow, for the
most
part the openser child processes servicing the
inside interface are
handling
responses (180,183,200) from the VM platform.
Call scenario:
When an INVITE arrives from the soft-switch, openser forwards it to the VM
platform. The VM platform responds with a 180 and then a 200. I've
noticed
several instances where the soft-switch did not
respond with an ACK. This
caused the VM platform to retransmit the 200 several times over a 10 second
period. These were absorbed correctly by openser for the duration of
wt_timer.
After the timer expired, however, each openser
child process that received
a
retransmitted 200 logged something like this:
4(2715) DEBUG: t_reply_matching: hash 45870 label 727647196 branch 0
4(2715) DEBUG: t_reply_matching: no matching transaction exists
4(2715) DEBUG: t_reply_matching: failure to match a transaction
4(2715) DEBUG: t_check: end=(nil)
When I look at the TM code, the static variable T in t_lookup.c is now NULL
for
this child process.
On a subsequent inbound call, the INVITE is passed to the VM correctly, and
the
180 transaction matches (causing the fr_inv_timer
to be armed). If the 200
is
read by child proc 2715, I see:
4(2715) DEBUG: t_check: start=(nil)
4(2715) DEBUG: t_check: T previously sought and not found
The 200 is forwarded back to the soft-switch, which responds with an ACK.
Both
end-points think the call is up, but since
openser never matched the 200
with
the call, the fr_inv_timer fires and cancels the
call. Basically, child
proc
2715 won’t match any transaction after this
unless it happens to process a
request.
I think this problem is made worse by the fact that I’m using two network
interfaces, and that the openser children on the inside interface handle
(for
the most part) only responses. This problem was
touched on here:
http://lists.openser.org/pipermail/users/2007-November/014188.html but I
didn’t see any follow up. Also, I’ve checked openser 1.2.3 and 1.3.1 for
fixes, but I don’t think this has been addressed.
I have a work around, I think, by upping the wt_timer to something like 15
seconds, but I was wondering if there is any scenario in which leaving
T=NULL
is
desirable.
Thanks in advance
Sean
6053
days inactive
6053
days old
1 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Sean O'Donnell