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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Oct 7 08:42:11 CEST 2009


Hi Brett,

Brett Nemeroff wrote:
> 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?
yes, it that case you will not get the ACK in the acc (at least not 
automatically, based on falgs) - but you can still do manual accounting 
(using acc_db_request() function)
>
> 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.
t_check_trans() is doing exactly what TM is automatically doing 
internally - there is no difference. The difference is when comes to 
handling the ACK - TM is doing some more complex processing (like 
callbacks, etc)
>
> 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?)
I would not call it a bug - maybe something that needs improvements and 
a bit of re-work. It is too late for 1.6, but definitely for 1.7.

Regards,
Bogdan

>
>
> 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 <mailto:Users at lists.opensips.org>
>     <mailto: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 <mailto:Users at lists.opensips.org>
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>
>
>     _______________________________________________
>     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
>   




More information about the Users mailing list