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

[Brett Nemeroff]

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/5cac95c2/attachment.htm