On that note, Bogdan's reply was on the sourceforge forum's :
there is known issue that ACK processing is a bit slower than the re-INVITE processing and they may swap order on opensips.... what you did was to bypass TM in opensips and forward statelessly the ACK (this is ACK is now much faster) and there is no swapping. -- Jeff Kronlage Senior IT Engineer, Data102 102 South Tejon, Suite #1250 Colorado Springs, CO 80903 (719) 387-0000 x 1335 direct (719) 578-8844 fax j...@data102.com / http://www.data102.com From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of Brett Nemeroff Sent: Monday, October 05, 2009 11:56 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Re-invite problem -> 491 Request Pending Jeff, Thanks for your reply. Is this in the loose route? or.. ? Does it break anything else? Bogdan, anyway you can explain what's going on here? :) -Brett On Mon, Oct 5, 2009 at 12:30 PM, Jeff Kronlage <j...@data102.com> wrote: Brett, I had this same exact problem. The solution was a little clunky but sending the ACK out statelessly solves the problem. My code looks like: t_check_trans(); if (is_method("ACK") && !t_check_trans()) { if (!forward()) sl_reply_error(); exit; } if (!t_relay()) sl_reply_error(); I wish I could give a more techie explanation on why this works - it was a hackjob answer for me. Bogdan posted an answer perhaps a week ago that explained it a bit. Cheers, -- Jeff Kronlage Senior IT Engineer, Data102 102 South Tejon, Suite #1250 Colorado Springs, CO 80903 (719) 387-0000 x 1335 direct (719) 578-8844 fax j...@data102.com / http://www.data102.com From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of Brett Nemeroff Sent: Monday, October 05, 2009 9:51 AM To: users@lists.opensips.org Subject: [OpenSIPS-Users] Re-invite problem -> 491 Request Pending Hello All, I'm not sure where the problem is.. it's either my switch, or it's the customer's box. What's happening is the customer sends a call. As soon as the 200OK gets back to them, they re-invite.. very fast. The reinvite occurs BEFORE the ACK for the 200OK makes it back to the provider. Because of this, when the RE-INVITE hits the provider they respond with "491 Request Pending", in other words, I can't process a re-invite because the last INVITE hasn't send me an ACK back yet. This happens over.. and over.. and over. What I'm wondering is if there is a timer I can adjust for this. Seems like OpenSIPs should know that the transaction is in a state where there is a PENDING ACK and it shouldn't process the RE-INVITE quite yet (Request Queued?). Perhaps that isn't a normal function of a Proxy. So I guess I'm looking for either a timer adjustment or a way to insert some sorta delay (sounds like a bad idea) to allow the ACK to traverse. The numbers are VERY close.. the ACK actually arrives at timestamp 12.757073, but the INVITE goes to the provider at 12.755913. So in other words, if the RE-INVITE occured 0.001161 seconds later, this wouldn't happen. Seems like there should be something to prevent these events? (A properly working UAC perhaps?!) Any ideas? Thanks, Brett _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users