16 Jan
2025
16 Jan
'25
1:08 p.m.
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>
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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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