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

Jeff Kronlage jeff at data102.com
Tue Oct 6 16:05:25 CEST 2009


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> 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>> 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> /
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>] *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>

>     *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 <mailto: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
>


_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20091006/302237fa/attachment.htm 


More information about the Users mailing list