Issue with ACK on INVITE

List overview All Threads
Download

newer

older

Use local_identity or custom data...

Kamailio v5.8.5 Released

Barry Flanagan

16 Jan 2025 16 Jan '25

12:50 p.m.

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

Attachments:

attachment.html (text/html — 3.5 KB)

Show replies by date

Daniel-Constantin Mierla

16 Jan 16 Jan

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:

...

-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

Barry Flanagan

1:27 p.m.

16 Jan 2025 18:09:03 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:

...

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:

-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

James Browne

21 Jan 21 Jan

11:07 a.m.

Hi Barry Also consider encode_contact() from the siputils module. https://www.kamailio.org/docs/modules/5.8.x/modules/siputils.html#siputils.… 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(a)lists.kamailio.org> wrote:

...

16 Jan 2025 18:09:03 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: 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(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 __________________________________________________________ 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!

Alex Balashov

22 Jan 22 Jan

8:09 p.m.

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(a)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.… 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(a)lists.kamailio.org> wrote:

__________________________________________________________ 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!

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

Who AmI

23 Jan 23 Jan

5:30 a.m.

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(a)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(a)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.…

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(a)lists.kamailio.org> wrote: > > 16 Jan 2025 18:09:03 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: > > 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(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 > > > __________________________________________________________ > 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!

__________________________________________________________ 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! -- 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(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!

days inactive

days old

sr-users@lists.kamailio.org

Manage subscription

5 comments

5 participants

tags (0)

participants (5)

Alex Balashov
Barry Flanagan
Daniel-Constantin Mierla
James Browne
Who AmI