[OpenSIPS-Users] ACK after set_advertised_address contains wrong address in VIA header

[Newlin, Ben]

I have opened issue #917 on Github [1].

I should mention that I have worked around this problem by deciding to use Record-Routes instead of set_advertised_address. It is much cleaner, even though it does expose my private IPs. However, I have kept this configuration in case you need me to perform any tests or get tracing/logs. Thanks!

[1] https://github.com/OpenSIPS/opensips/issues/917

Ben Newlin

From: "Newlin, Ben" <Ben.Newlin at inin.com>
Date: Monday, June 27, 2016 at 11:06 AM
To: Bogdan-Andrei Iancu <bogdan at opensips.org>, "users at lists.opensips.org" <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] ACK after set_advertised_address contains wrong address in VIA header

Did you mean to say if you set it in request route?

I should clarify that when I am setting the advertised address the second time it is of course happening in failure_route as the first request has failed at that point. Perhaps that is the issue?

I will open a bug. Thanks.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Monday, June 27, 2016 at 10:41 AM
To: "Newlin, Ben" <Ben.Newlin at inin.com>, "users at lists.opensips.org" <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] ACK after set_advertised_address contains wrong address in VIA header

Hi Ben,

If you set the advertised host / port in branch route, it will have impact over the entire transaction (all branches). So, any local replies (CANCEL and ACK) that are constructed by OpenSIPS (for any branch) will use the same set of advertised values. Which is of course wrong. Let us come up with the fix (as idea and code).

Could you open a  bug report on the GITHUB tracker, please ?

Regards,




Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 27.06.2016 15:45, Newlin, Ben wrote:
I always set the advertised address in request route.

Also as the original issue noted the second INVITE does go out with the correct advertised address in the VIA. It is only the local ACK for the failed second request that contains the wrong address in the VIA. So set_advertised_address appears to be working, but the local generated ACK is not using that address.


Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Monday, June 27, 2016 at 5:37 AM
To: "users at lists.opensips.org"<mailto:users at lists.opensips.org> <users at lists.opensips.org><mailto:users at lists.opensips.org>, "Newlin, Ben" <Ben.Newlin at inin.com><mailto:Ben.Newlin at inin.com>
Subject: Re: [OpenSIPS-Users] ACK after set_advertised_address contains wrong address in VIA header

Hi Ben,

Where in the script do you do the first advertise_address ? In the request route or in a branch route ?

Regards,




Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 25.06.2016 03:41, Newlin, Ben wrote:
I have run into the same problem that was described in this previous post [1], however it doesn’t appear it was ever solved at the time.

I am using the dispatcher module to route calls to external carriers and I am using set_advertised_address to set the outgoing public address prior to sending the request. If the first destination returns failure, the ACK is sent correctly. Then I select a different destination and set a different public address using set_advertised_address. If this second call also fails, the ACK that is sent out uses the first advertised address, not the current on for the request.

Has anyone figured this out? I am using 1.11.6.

[1] http://lists.opensips.org/pipermail/users/2014-August/029779.html


Ben Newlin






_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto: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/20160627/55e233e4/attachment-0001.htm>