[OpenSIPS-Users] ACK mangling redux - OpenSIPS 1.7

[Vlad Paiu]

Hello,

In the latest pastebin config you provided the error is still present.
You have
       if(!is_method("REGISTER")) {
                 if(loose_route()) {
                         route(1);
                 }
       }

So for ACKs, you will do loose_route(), it will succeed and then you 
will call route(1), which calls rewritehostport() . So basically, 
nothing was different compared to your previous scenario, you still 
rewrite the RURI for ACKs.

Please take a closer look at the default scripting scenario that comes 
with OpenSIPS.
Basically, the sequential requests processing ( ACKs, ReINVITEs, etc ) 
should look something like :

     if (has_totag()) {
         # sequential request withing a dialog should
         # take the path determined by record-routing
         if (loose_route()) {
             # route it out to whatever destination was set by loose_route()
             # in $du (destination URI).
             if (!t_relay()) {
                 sl_reply_error();
             };
             exit;
         } else {
             if ( is_method("ACK") ) {
                 if ( t_check_trans() ) {
                     # non loose-route, but stateful ACK; must be an ACK 
after-
                     # a 487 or e.g. 404 from upstream server
                     t_relay();
                     exit;
                 } else {
                     # ACK without matching transaction ->
                     # ignore and discard
                     exit;
                 }
             }
             sl_send_reply("404","Not here");
         }
     }

Regards,

Vlad Paiu
OpenSIPS Developer


On 09/06/2011 06:17 PM, Jock McKechnie wrote:
>
>
> On Mon, Sep 5, 2011 at 2:49 AM, Vlad Paiu <vladpaiu at opensips.org 
> <mailto:vladpaiu at opensips.org>> wrote:
>
>     Hello Jock,
>
>     I have taken a look at the SIP trace and seems that the proxy
>     behind Charlie, 192.168.1.1, does some weird stuff to the ACK.
>     More specifically, it mangles the domain part of the RURI, so that
>     it points to 192.168.1.4. When Charlie ( 192.168.1.4 ) receives
>     this ACK it sees itself in the domain part of the RURI, so it
>     applies strict routing, by taking the last route header and
>     putting it in the RURI. This is why you see the apparent stripping
>     of the username part when forwarding the ACK.
>
>     I guess a good question is why are you calling
>         rewritehostport("192.168.1.4:5060 <http://192.168.1.4:5060>");
>     on the proxy behind Charlie ? Because this is the source of your
>     problem. I mean why not let the ACK get routed like every other
>     sequential request, via the Route header.
>
>
> Thank you, Vlad;
>
> I think I'm following what you're explaining - I'm force-routing the 
> ACKs instead of letting the handler route them based by the rules in 
> the header itself. I changed the configuration to the below, which 
> should only force the INVITE to Charlie, and use a t_relay() to handle 
> the ACKs, et al, correctly:
>
>         if (is_method("INVITE")) {
>                 # enable Record-Route
>                 record_route();
>                 route(1);
>                 }
>
>         if (!t_relay()) {
>                 sl_reply_error();
>                 }
>
> Unfortunately this appears to make no difference to how the ACK's RURI 
> looks. I imagine I'm using the wrong method of forwarding on the ACK?
> (Full config is here, should you want to see it in context: 
> http://pastebin.com/Zntg2y95)
>
> Thank you, again, for your assistance and suggestions. I am immensely 
> grateful for all help I receive on this list.
>
>  - Jock
>
>
> _______________________________________________
> 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/20110906/34b6df37/attachment.htm>