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