Hi Jeff, Some time, simply experiment with some configurations may provide a quicker solution rather than start digging to the bottom to see what's happening - of course, this is a good approach only for quick fixes - as you said, at a point, you really need to "understand" how it's working.
calling t_check_trans() twice, for any method (except ACK and CANCEL requests) simply returns the same result as first one (without any processing). So,if you have an ACK - do not "abuse" this function as it will do the matching each time you call it. Regards, Bogdan Jeff Kronlage wrote: > > Bogdan, > > I apologize for ‘beating a dead horse’. I get that this is a > frustration we’re stuck with for various reasons. > > I’ve been writing my Opensips config on a daily basis for going on six > months now, and there’s still a couple of “weird” spots in my scripts > that drive me nuts (I literally have a comment above this code that > says “NEEDS DEBUGGING”). > > For anyone interested in the topic, please understand that I wrote > this particular fix ‘under the gun’, we’d just launched our product > and a handful of our customers couldn’t receive calls from a network > we’re peered with because their proxy server fired off an immediate > reinvite and my system couldn’t accept it. This went so far as the > peered telco beginning to call me (unsuccessfully, of course! J) > because they were getting tickets from their users unable to contact mine. > > Having said that, I was in a hurry, and came up with the code below. I > still to this day don’t understand why calling t_check_trans() twice > was necessary, but I can say that if I eliminate one of them, the > system breaks down. > > Any advice? Like any good IT/Developer type, I’d like to totally > understand what my script is doing J > > Cheers, > > Jeff Kronlage > > Data102// > > *From:* [email protected] > [mailto:[email protected]] *On Behalf Of *Brett Nemeroff > *Sent:* Tuesday, October 06, 2009 7:15 AM > *To:* OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] Re-invite problem -> 491 Request Pending > > 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] <mailto:[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]> > > > <mailto:[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]> <mailto:[email protected] > <mailto:[email protected]>> / http://www.data102.com > > > > > *From:* [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > [mailto:[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]> > <mailto:[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] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
