[OpenSIPS-Users] ACK mangling redux - OpenSIPS 1.7

Jock McKechnie jock.mckechnie at gmail.com
Tue Sep 6 19:23:28 CEST 2011


Vlad;

In not seeing the forest for the trees I missed that !loose_route() call,
very sloppy on my part. I was also not fully versed in how this mechanism
worked to begin with, however, but am now.

Testing shows this was, indeed, the issue. I thank you again, very much, for
your time in helping me out with my problem here.

Have a wonderful week all;

 - Jock


On Tue, Sep 6, 2011 at 10:45 AM, Vlad Paiu <vladpaiu at opensips.org> wrote:

> **
> 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> 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");
>> 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.orghttp://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/20110906/2add2abf/attachment.htm>


More information about the Users mailing list