Bogdan,I presently record the 200 OK ACK in my ACC, but I don't seem to actually utilize it for anything at present. If I did the fix jeff mentioned, will I no longer get that ACK in ACC?
so performing the t_check_trans() is faster than tm module's built in matching? I'm not sure I get why this is faster. I would have thought that the work t_check_trans does is similar to what the tm module already does. BTW ,is this a bug that is planned to be fixed? Or should I just expect that this scripting fix be a regular part of my scripts (if so, perhaps it should be in the example scripts?) Thanks, Brett On Tue, Oct 6, 2009 at 8:01 AM, Bogdan-Andrei Iancu <[email protected]>wrote: > Hi Brett, > > This is an ancient topic that needs to be solved once for all. The > bottom problem is that OpenSIPS / TM does try o match the 200OK ACK > against the INVITE transaction - and it should not do that as 200OK ACK > forms a separate transaction and it matches at dialog level, not > transaction level. Because of this, the 200OK ACK matching is not > reliable (especially if you do spirals on opensips) and it is also time > consuming. > > Because of this, the 200OK ACK matching takes longer than processing of > a re-INVITE and here comes the changing in order. > > IMO, this artificial / forced matching of 200 OK should be dropped. > > But there are 2 modules using this: > ACC - for accounting ACK for 200 OK - not sure how many people do enable > this > OSP - no clue :D..... > > Regards, > Bogdan > > Brett Nemeroff wrote: > > 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 <[email protected] > > <mailto:[email protected]>> 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 > > > > [email protected] <mailto:[email protected]> / http://www.data102.com > > > > *From:* [email protected] > > <mailto:[email protected]> > > [mailto:[email protected] > > <mailto:[email protected]>] *On Behalf Of *Brett > > Nemeroff > > *Sent:* Monday, October 05, 2009 9:51 AM > > *To:* [email protected] <mailto:[email protected]> > > *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 > > [email protected] <mailto:[email protected]> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
