[OpenSIPS-Users] Re-invite problem -> 491 Request Pending

Jeff Pyle jpyle at fidelityvoice.com
Thu Nov 19 21:33:46 CET 2009 

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" <jpyle at fidelityvoice.com> 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" <bogdan at voice-system.ro> 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:* users-bounces at lists.opensips.org
>>> [mailto:users-bounces at lists.opensips.org] *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
>>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> 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 <jeff at data102.com
>>> <mailto:jeff at data102.com>
>>> 
>>>> <mailto:jeff at data102.com <mailto:jeff at 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
>>>> 
>>> 
>>>> jeff at data102.com <mailto:jeff at data102.com> <mailto:jeff at data102.com
>>> <mailto:jeff at data102.com>> / http://www.data102.com
>>> 
>>>> 
>>>> *From:* users-bounces at lists.opensips.org
>>> <mailto:users-bounces at lists.opensips.org>
>>>> <mailto:users-bounces at lists.opensips.org
>>> <mailto:users-bounces at lists.opensips.org>>
>>>> [mailto:users-bounces at lists.opensips.org
>>> <mailto:users-bounces at lists.opensips.org>
>>>> <mailto:users-bounces at lists.opensips.org
>>> <mailto:users-bounces at lists.opensips.org>>] *On Behalf Of *Brett
>>>> Nemeroff
>>>> *Sent:* Monday, October 05, 2009 9:51 AM
>>> 
>>>> *To:* users at lists.opensips.org <mailto:users at lists.opensips.org>
>>> <mailto:users at lists.opensips.org <mailto:users at 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 at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

More information about the Users mailing list