[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