Update... INVITEs make it through in 62ms, but ACKs in 95ms. And from the carrier the reINVITE comes in only 5ms after the ACK.
- Jeff On 11/19/09 3:21 PM, "Jeff Pyle" <[email protected]> wrote: > Hello, > > I was reading through and I've come to the conclusion the horse just isn't > dead enough. :) > > Bogdan referred to "fixing this once and for all", and I was wondering if > that had happened in 1.6. > > If not, where is the appropriate place to insert the workaround Jeff K. had > come up with? I've tried it in various configurations in loose_route(), > since that's where the packets seem to hit. I have the same result every > time on 1.5.3. It takes 3ms to forward an INVITE but 6ms to forward an ACK. > Since the carrier in my case is sending the two less than 1ms apart, it > doesn't work so well. > > Any suggestions would be great. > > > Thanks, > Jeff > > > > On 10/7/09 2:50 AM, "Bogdan-Andrei Iancu" <[email protected]> wrote: > >> 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 > > > _______________________________________________ > 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
