Yes. Thanks!
Sean O'Donnell Senior Engineer uReach Technologies, Inc. 877-721-6126---- On Fri, 9 May 2008, Bogdan-Andrei Iancu ([EMAIL PROTECTED]) wrote:
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 ([EMAIL PROTECTED]) 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, > > > > Im using openser as a call distributor/proxy between a soft-switch/SBC and > > voicemail platform. Im seeing a problem with openser in that it is > sometimes > > cancels an in-progress call (fr_inv_timer firing) because it didnt 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 wont match any transaction after this unless it happens to process a > > request. > > > > I think this problem is made worse by the fact that Im 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 > > didnt see any follow up. Also, Ive checked openser 1.2.3 and 1.3.1 for > > fixes, but I dont 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 > > > > > > > > >
_______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
