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
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@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!
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
Hi Barry Also consider encode_contact() from the siputils module. https://www.kamailio.org/docs/modules/5.8.x/modules/siputils.html#siputils.f...
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!
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...
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!
This is a great option, I do this manually currently. Thanks for the heads up here.
John
On Thu, 23 Jan 2025, 01:50 Alex Balashov via sr-users, < sr-users@lists.kamailio.org> wrote:
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...
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!
-
Alex Balashov -
Barry Flanagan -
Daniel-Constantin Mierla -
James Browne -
Who AmI