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

[Jeff Pyle]

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