encode_contact() is fantastic, making automatic and turn-key that which used to have to be done manually, and quite labouriously.

-- Alex

> On Jan 21, 2025, at 11:07 am, James Browne via sr-users <sr-users@lists.kamailio.org> wrote:
>
> Hi Barry
> Also consider encode_contact() from the siputils module.
> https://www.kamailio.org/docs/modules/5.8.x/modules/siputils.html#siputils.f.encode_contact
>
> That can help to avoid them detecting NAT and wrecking the RURI.
>
> James
>
> On Thu, 16 Jan 2025 at 18:36, Barry Flanagan via sr-users
> <sr-users@lists.kamailio.org> wrote:
>>
>> 16 Jan 2025 18:09:03 Daniel-Constantin Mierla <miconda@gmail.com>:
>>
>> Hello,
>>
>> there is another proxy in the path of SIP signalling in the provider side because it adds Record-Route:
>>
>> Record-Route: <sip:182.33.174.10;lr;ftag=as0b42eef3>
>>
>>
>> Thanks Daniel,
>>
>> Yes, my feeling was they were treating us as NAT and have asked them to check that and disable it. I do think they use kamailio on their end.
>>
>> Thanks
>>
>> -Barry Flanagan
>>
>> Having the ftag parameter, likely to be another Kamailio or one of its forks. But that proxy does wrongly nat traversal processing, replacing the contact address with the source ip and port (the old style with fix_nated_contact()), but nat traversal should be done only when the proxy is in the immediate vicinity of the NAT router, which is not the case here, so it should do no nat traversal.
>>
>> If you can change that with the provider, then yours should be fine. If not, you can add contact alias with set_contact_alias() function to the requests/replies sent to the provider and then handle requests within dialog with handle_ruri_alias().
>>
>> Alternative could be to use topos module, but it adds processing overhead. Other alternatives: use dialog module and recover the contact uri from it, or store the contact uri in a htable and recover it when needed.
>>
>> Cheers,
>> Daniel
>>
>> On 16.01.25 18:50, Barry Flanagan via sr-users wrote:
>>
>> Hi folks,
>>
>> Trying to hook up a new endpoint but am having an issue. Kamailio is in front of an Asterisk box.
>>
>> They send an INVITE, we send 100, then 200 OK. However, when they send their ACK, the RURI is not set to the Contact of the 200, instead it is<number>@<proxy ip>. This causes the ACK to get routed to the proxy itself and the call fails.
>>
>> 82.160.190.100:5060 = Kamailio IP Port
>> 198.201.240.242:5080 = Asterisk IP/Port
>> 182.33.174.10:5060 = Provider endpoint
>>
>> The far endpoint say they cannot fix the RURI - should I be able to handle this ACK below? My understanding is the ACK's RURI should be the Contact of the 200 OK.
>>
>> 200 OK sent from us to the Provider (Contact shows correct URI)
>> =========================================================
>> 2025/01/15 17:14:49.470634 82.160.190.100:5060 -> 182.33.174.10:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 182.33.174.10;branch=z9hG4bKefc7.ad07f2d3.0
>> Via: SIP/2.0/UDP 182.33.174.39:5060;received=182.33.174.39;branch=z9hG4bK5bbf9591;rport=5060
>> Record-Route: <sip:1800715080@82.160.190.100:5061;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>
>> Record-Route: <sip:1800715080@82.160.190.100;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>
>> Record-Route: <sip:182.33.174.10;lr;ftag=as0b42eef3>
>> From: "0737965510" <sip:0737966610@182.33.174.39>;tag=as0b42eef3
>> To: <sip:1800715080@82.160.190.100>;tag=as4133584e
>> Call-ID: 480dc17b3f88516f364778dc4b2528da@182.33.174.39:5060
>> CSeq: 102 INVITE
>> Server: Asterisk PBX 18.9.0
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>> Supported: replaces
>> Contact: <sip:1800715080@198.201.240.242:5080>
>> Content-Type: application/sdp
>> Content-Length: 314 ,
>>
>> ACK Reply from Provider to Us (RURI points to Kamailio ip:port now
>> ===========================================================
>> 2025/01/15 17:14:49.478119 182.33.174.10:5060 -> 82.160.190.100:5060
>> ACK sip:1800715080@82.160.190.100:5060 SIP/2.0
>> Via: SIP/2.0/UDP 182.33.174.10;branch=z9hG4bKefc7.ad07f2d3.2
>> Via: SIP/2.0/UDP 182.33.174.39:5060;received=182.33.174.39;branch=z9hG4bK55656469;rport=5060
>> Route: <sip:1800715080@82.160.190.100;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>,sip:1800715080@82.160.190.100:5061;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>
>> Max-Forwards: 69
>> From: "0737965510" <sip:0737966610@182.33.174.39>;tag=as0b42eef3
>> To: <sip:1800715080@82.160.190.100>;tag=as4133584e
>> Contact: <sip:0737965510@182.33.174.39:5060>
>> Call-ID: 480dc17b3f88516f364778dc4b2528da@182.33.174.39:5060
>> CSeq: 102 ACK
>>
>>
>> Thanks
>>
>> -Barry
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
>> To unsubscribe send an email to sr-users-leave@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>
>>
>> --
>> Daniel-Constantin Mierla (@ asipto.com)
>> twitter.com/miconda -- linkedin.com/in/miconda
>> Kamailio Consultancy, Training and Development Services -- asipto.com
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
>> To unsubscribe send an email to sr-users-leave@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
> To unsubscribe send an email to sr-users-leave@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!