I am extremely new at this, but trying to set up TLS with a carrier. TLS connection is good, Invite goes out, we get the 100 and the 200, but subsequent messages (ACK and BYE) are being sent with UDP and I cannot figure out how to get them to maintain the TLS transport. Any suggestions? I think this is the section I'm looking for.
# Manage incoming replies in transaction context onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n");
if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } if (has_body("application/sdp")) { xdbg("rtpengine_manage loop-protect MANAGE_REPLY"); #rtpengine_manage("loop-protect"); } }
El Wed, 19 Jun 2024 19:54:26 -0000 "sarah.martin--- via sr-users" sr-users@lists.kamailio.org escribió:
I am extremely new at this, but trying to set up TLS with a carrier. TLS connection is good, Invite goes out, we get the 100 and the 200, but subsequent messages (ACK and BYE) are being sent with UDP and I cannot figure out how to get them to maintain the TLS transport. Any suggestions? I think this is the section I'm looking for.
What's your contact look like?
I replaced IPs, FYI
200 OK from carrier SIP/2.0 200 OK Via: SIP/2.0/TLS KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De From: "+14388006102" sip:+14388006102@KAM_PUB_IP;tag=XjQ5g4Ze5UaZp To: sip:933@CARRIER_PUB_IP:5061;transport=tls;tag=gK04d33797 Call-ID: b99c2b65-a827-123d-1984-4201c0a80193 CSeq: 84807919 INVITE Record-Route: sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: sip:933@CARRIER_PUB_IP:5061 Allow: INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: timer Supported: timer Session-Expires: 1800;refresher=uac Content-Length: 324 Content-Disposition: session; handling=required Content-Type: application/sdp
v=0 o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP s=SIP Media Capabilities c=IN IP4 206.146.100.22 t=0 0 m=audio 33168 RTP/SAVP 0 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20
ACK Kam is sending
ACK sip:933@CARRIER_PUB_IP:5061 SIP/2.0 Via: SIP/2.0/UDP KAM_PUB_IP:5060;branch=z9hG4bK18ff.f8c56ea9cad44dc10408188224b923cf.0;i=a2 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKmK767vF2vjZ0S Max-Forwards: 69 From: "+14388006102" sip:+14388006102@KAM_PUB_IP;tag=XjQ5g4Ze5UaZp To: sip:933@CARRIER_PUB_IP:5061;transport=tls;tag=gK04d33797 Call-ID: b99c2b65-a827-123d-1984-4201c0a80193 CSeq: 84807919 ACK Contact: sip:mod_sofia@FS_PUB_IP:5061;transport=tls;alias=FS_PUB_IP~56403~3 Content-Length: 0
Hi
The INVITE would also be interesting.
Does the Contact: Header in the invite contain the transport=tls attribute?
Souldn't the 200 OK reply contain at least one Record-Route (the lowest one) stating transport=tls?
PS: I was facing a similar issue with a commercial SBC which, when TLS/TCP is not licensed, has the oddity to remove the transport attribute from the contact header and send new transactions in the same dialog without specifying transport (defaulting to UDP). So I had to create a copy the value of the transport header to a custom t= contact attribute, which I then use to restore the U-URI transport attribute towards the registrar handling the CPE connection.
200 OK from carrier SIP/2.0 200 OK Via: SIP/2.0/TLS KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De From: "+14388006102" sip:+14388006102@KAM_PUB_IP;tag=XjQ5g4Ze5UaZp To: sip:933@CARRIER_PUB_IP:5061;transport=tls;tag=gK04d33797 Call-ID: b99c2b65-a827-123d-1984-4201c0a80193 CSeq: 84807919 INVITE Record-Route: sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: sip:933@CARRIER_PUB_IP:5061 Allow: INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: timer Supported: timer Session-Expires: 1800;refresher=uac Content-Length: 324 Content-Disposition: session; handling=required Content-Type: application/sdp
v=0 o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP s=SIP Media Capabilities c=IN IP4 206.146.100.22 t=0 0 m=audio 33168 RTP/SAVP 0 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20
ACK Kam is sending
ACK sip:933@CARRIER_PUB_IP:5061 SIP/2.0 Via: SIP/2.0/UDP KAM_PUB_IP:5060;branch=z9hG4bK18ff.f8c56ea9cad44dc10408188224b923cf.0;i=a2 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKmK767vF2vjZ0S Max-Forwards: 69 From: "+14388006102" sip:+14388006102@KAM_PUB_IP;tag=XjQ5g4Ze5UaZp To: sip:933@CARRIER_PUB_IP:5061;transport=tls;tag=gK04d33797 Call-ID: b99c2b65-a827-123d-1984-4201c0a80193 CSeq: 84807919 ACK Contact: sip:mod_sofia@FS_PUB_IP:5061;transport=tls;alias=FS_PUB_IP~56403~3 Content-Length: 0 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Mit freundlichen Grüssen
-Benoît Panizzon-
Originating invite towards carrier. Yes, the contact includes the transport=tls.
INVITE sip:933@CARRIER_PUB_IP:5061;transport=tls SIP/2.0 Record-Route: sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=09c1cZr21c5HF;did=dbd.79d;nat=yes Via: SIP/2.0/TLS KAM_PUB_IP:5061;branch=z9hG4bK317b.e2cd4e0e036cc3a13f6bb1a86e1db84e.0;i=f1 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=39577;branch=z9hG4bKF0jKaBSBpQtXF Max-Forwards: 69 From: "2029200292" sip:2029200292@KAM_PUB_IP;tag=09c1cZr21c5HF To: sip:933@CARRIER_PUB_IP:5061;transport=tls Call-ID: 8460387e-a536-123d-1984-4201c0a80193 CSeq: 84646169 INVITE Contact: sip:mod_sofia@FS_PUB_IP:5061;transport=tls;alias=FS_PUB_IP~39577~3 User-Agent: FreeSWITCH-mod_sofia/1.10.7-release-19-883d2cb662~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 753 X-FS-Support: update_display,send_info P-Asserted-Identity: "2029200292" sip:2029200292@KAM_PUB_IP P-Hint: outbound
v=0 o=FreeSWITCH 1718380362 1718380363 IN IP4 KAM_PUB_IP s=FreeSWITCH c=IN IP4 KAM_PUB_IP t=0 0 a=rtpengine:94805c0d8314 m=audio 11080 RTP/SAVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:11081 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9Qjov4TJ7gCTZ1QXBcvg5zwRmNE5d1A6OEfmY7Lz a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:ue9JN4KAuPD9xsJwC1HzQflx67IY8+dOpnYszoyJ a=crypto:3 F8_128_HMAC_SHA1_80 inline:04FfXKIKe9NlS6JaQjiCqEGGs7pJs7yPINkwxU+p a=crypto:4 F8_128_HMAC_SHA1_32 inline:RJJdhXJ7iP+l7ssqqbWxZmZN3kU09VDZe9Vp+0dt a=setup:actpass a=fingerprint:sha-256 E6:F5:49:C1:2A:33:E2:F5:22:7E:7D:E0:EA:3D:77:0C:45:50:B8:8F:20:4D:C4:BA:8F:5F:3D:57:F5:94:B4:8F a=ptime:20
Hi
Originating invite towards carrier. Yes, the contact includes the transport=tls.
I think I'm missing something.
Which message is not correctly routed?
The 200 OK reply to an INVITE which was initiated via transport tls? Or messages in a new transaction of that call, possibly from the B to A side?
Mit freundlichen Grüssen
-Benoît Panizzon-
FS-->Kam-->Carrier
Invite to carrier is good, sent over tls and so the reply from the carrier, the 200 ok. The ACK is sent via UDP and so is the Bye, which I didn't include.
Am Thu, 20 Jun 2024 14:14:11 -0000 schrieb smartin114--- via sr-users sr-users@lists.kamailio.org:
Invite to carrier is good, sent over tls and so the reply from the carrier, the 200 ok. The ACK is sent via UDP and so is the Bye, which I didn't include.
I fear I need more information and a complete example to see what might be going wrong.
INVITE: FS => TLS => Kamailio => UDP => Carrier some more messages 200 OK: Carrier => UDP => Kamailio => TLS => FS and the ACK to the 200 OK, they are all fine?
So the Problem is the BYE when sent which direction? From the Carrier?
I assume this is the case.
Basically you need to look at the INVITE from the FS.
Does the Contact: header contain a transport=tls attribute? (According to your example, it does)
So this information needs to be stored on the Carrier side (or whatever B2BUA an the Carrier side handles the call) and when the carrier issues a BYE the R-URI of that BYE needs to contain transport=tls as this is the information, the last HOP towards the Fs side will be using when all Route: Header have been consumed.
If this is NOT the case and transport=tls is missing in the BYE R-URI the IMHO SIP implementation Carries side is 'broken', you face the same issue I have had. :-)
If you are able to put other attributes in the invite Contact header, and they are sent back the BYE from the Carrier, then you can copy the transport value to a custom contact attribute (I use t=) and restore the transport attribute on the R-URI from that.
Mit freundlichen Grüssen
-Benoît Panizzon-
everything from FS to Kam shows TLS and good. It's just the leg between Kam and the carrier. The invite goes from Kam to the carrier (the one I pasted above), the carrier 200ok's it, also good, then Kam sends the ACK over UDP, so the carrier never actually sees it - because they aren't listening on 5060 for this connection and the carrier retransmits the 200 until the call terminates. When Kam initiates the Bye, it is also over UDP. When Kam responds to the carrier Bye that eventually comes, it sends that over TLS.
can you show the 200 OK?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Thu, Jun 20, 2024 at 5:43 PM smartin114--- via sr-users < sr-users@lists.kamailio.org> wrote:
I was trying to add an attachment of the call flow, but I don't see that I can? __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
it is already in the thread.
200 OK from carrier SIP/2.0 200 OK Via: SIP/2.0/TLS KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De From: "+14388006102" sip:+14388006102@KAM_PUB_IP;tag=XjQ5g4Ze5UaZp To: sip:933@CARRIER_PUB_IP:5061;transport=tls;tag=gK04d33797 Call-ID: b99c2b65-a827-123d-1984-4201c0a80193 CSeq: 84807919 INVITE Record-Route: sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: sip:933@CARRIER_PUB_IP:5061 Allow: INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: timer Supported: timer Session-Expires: 1800;refresher=uac Content-Length: 324 Content-Disposition: session; handling=required Content-Type: application/sdp
v=0 o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP s=SIP Media Capabilities c=IN IP4 CARRIER_PUB_IP t=0 0 m=audio 33168 RTP/SAVP 0 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20
You trying to add the XML to the sdp? Are you manipulating something somewhere? It is very strange indeed... have you tried force_socket?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Thu, Jun 20, 2024 at 7:06 PM smartin114--- via sr-users < sr-users@lists.kamailio.org> wrote:
it is already in the thread.
200 OK from carrier SIP/2.0 200 OK Via: SIP/2.0/TLS KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2 Via: SIP/2.0/TLS FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De From: "+14388006102" sip:+14388006102@KAM_PUB_IP;tag=XjQ5g4Ze5UaZp To: sip:933@CARRIER_PUB_IP:5061;transport=tls;tag=gK04d33797 Call-ID: b99c2b65-a827-123d-1984-4201c0a80193 CSeq: 84807919 INVITE Record-Route:
sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: sip:933@CARRIER_PUB_IP:5061 Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: timer Supported: timer Session-Expires: 1800;refresher=uac Content-Length: 324 Content-Disposition: session; handling=required Content-Type: application/sdp
v=0 o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP s=SIP Media Capabilities c=IN IP4 CARRIER_PUB_IP t=0 0 m=audio 33168 RTP/SAVP 0 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
I haven't tried force_socket. Where would that be added?
No manipulating. I was stripping off some of the crypto suites, but that is about it.
you'd need to mark the reply and before forwarding it, force_socket it to your tls socket You do have a TLS socket, right?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Thu, Jun 20, 2024 at 7:31 PM smartin114--- via sr-users < sr-users@lists.kamailio.org> wrote:
and no, not adding XML to the SDP. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Yes, there is a tls socket defined. I assume since the invite goes out TLS and all the cert stuff works, there is a tls socket as well.
is there a UDP socket a well? are you translating TLS<->UDP?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Thu, Jun 20, 2024 at 10:48 PM smartin114--- via sr-users < sr-users@lists.kamailio.org> wrote:
Yes, there is a tls socket defined. I assume since the invite goes out TLS and all the cert stuff works, there is a tls socket as well. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
check https://github.com/davidcsi/kamailio-private-public/blob/master/kamailio-tls... that might give you some ideas
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Thu, Jun 20, 2024 at 11:23 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
is there a UDP socket a well? are you translating TLS<->UDP?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Thu, Jun 20, 2024 at 10:48 PM smartin114--- via sr-users < sr-users@lists.kamailio.org> wrote:
Yes, there is a tls socket defined. I assume since the invite goes out TLS and all the cert stuff works, there is a tls socket as well. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
In the end it was a very straight forward change. If the call comes in on port 5061 set a TLS flag, then in the relay, if the flag is set call t_relay_tls vs t_relay
Thanks for reporting back.
Henning
-----Original Message----- From: smartin114--- via sr-users sr-users@lists.kamailio.org Sent: Tuesday, June 25, 2024 9:34 PM To: sr-users@lists.kamailio.org Cc: smartin114@me.com Subject: [SR-Users] Re: replies using the wrong protocol
In the end it was a very straight forward change. If the call comes in on port 5061 set a TLS flag, then in the relay, if the flag is set call t_relay_tls vs t_relay __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
good that you resolved it. Regards,
David Villasmil email: david.villasmil.work@gmail.com
On Thu, Jun 27, 2024 at 2:32 PM Henning Westerholt via sr-users < sr-users@lists.kamailio.org> wrote:
Thanks for reporting back.
Henning
-----Original Message----- From: smartin114--- via sr-users sr-users@lists.kamailio.org Sent: Tuesday, June 25, 2024 9:34 PM To: sr-users@lists.kamailio.org Cc: smartin114@me.com Subject: [SR-Users] Re: replies using the wrong protocol
In the end it was a very straight forward change. If the call comes in on port 5061 set a TLS flag, then in the relay, if the flag is set call t_relay_tls vs t_relay __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
-
Benoit Panizzon -
David Villasmil -
Henning Westerholt -
Jon Bonilla (Manwe) -
sarah.martin＠nextiva.com -
smartin114＠me.com