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

[Bogdan-Andrei Iancu]

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
> >
>