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 <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