Problem with TLS

List overview All Threads
Download

newer

older

unable to bring up kamailio 5.1.4

Disable basic authentication?

Arik Halperin

5 Jun 2018 5 Jun '18

4:56 a.m.

Hello, I’m using TLS After receiving 200OK from kamailio: r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP: (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS 70.36.25.65:443: SIP/2.0 200 OK Via: SIP/2.0/TLS 10.134.232.109:44097;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB-Qh78PmIQFrRk;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> From: "number" <sips:972523391991@kamprod.telemessage.com<mailto:972523391991@kamprod.telemessage.com>>;tag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO To: <sips:1111111@kamprod.telemessage.com<mailto:1111111@kamprod.telemessage.com>>;tag=64H63g861ajHj Call-ID: Sq4jR85o3Caz2XTXo-71FKAdbJ1x9vz2 CSeq: 8107 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: ti PJSIP responds with: Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session What is the reason for this? How can I fix this issue? Thanks, Arik Halperin

Attachments:

attachment.html (text/html — 7.9 KB)

Show replies by date

Daniel-Constantin Mierla

11 Jun 11 Jun

6:43 a.m.

Hello, Kamailio is not involved in the issue reported here. Practically, pjsip expects sips: scheme in the contact URI, which was set by FreeSwitch in 200ok. Maybe there is an option that you have to turn on for FreeSwitch to use sips: scheme. Otherwise, you can try to replace sip with sips in kamailio config and do the reverse the other way. Cheers, Daniel On 05.06.18 06:56, Arik Halperin wrote:

...

Hello, I’m using TLS After receiving 200OK from kamailio: r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP: (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS 70.36.25.65:443: SIP/2.0 200 OK Via: SIP/2.0/TLS 10.134.232.109:44097;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB-Qh78PmIQFrRk;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> From: "number" <sips:972523391991@kamprod.telemessage.com <mailto:972523391991@kamprod.telemessage.com>>;tag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO To: <sips:1111111@kamprod.telemessage.com <mailto:1111111@kamprod.telemessage.com>>;tag=64H63g861ajHj Call-ID: Sq4jR85o3Caz2XTXo-71FKAdbJ1x9vz2 CSeq: 8107 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: ti *PJSIP responds with:* * * *Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session* * * What is the reason for this? How can I fix this issue? Thanks, Arik Halperin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com

Arik Halperin

7:51 a.m.

Daniel, Thank you! You are right about this. I configured PJSIP not to check whether the contact contains SIPS. This solved the problem on one of my setups where I have one NIC that has a public IP. However on the original setup, the kamailio has one public IP and one private IP. In that setup, the ACK to the 200 OK is not forwarded over the private IP to the freeswitch. This only happens in TLS, when I work with TCP it works well. I believe it is somehow connected to the record route, and I’m looking into PJSIP to try to find the answer, but is there anything I could do in the kamailio? I have the same problems with other SIP clients(Bria for example) Thanks, Arik Halperin On 11 Jun 2018, at 9:43, Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: Hello, Kamailio is not involved in the issue reported here. Practically, pjsip expects sips: scheme in the contact URI, which was set by FreeSwitch in 200ok. Maybe there is an option that you have to turn on for FreeSwitch to use sips: scheme. Otherwise, you can try to replace sip with sips in kamailio config and do the reverse the other way. Cheers, Daniel On 05.06.18 06:56, Arik Halperin wrote: Hello, I’m using TLS After receiving 200OK from kamailio: r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP: (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS 70.36.25.65:443: SIP/2.0 200 OK Via: SIP/2.0/TLS 10.134.232.109:44097;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB-Qh78PmIQFrRk;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> From: "number" <sips:972523391991@XXXXXXX.com<mailto:972523391991@kamprod.telemessage.com>>;tag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO To: <sips:1111111@XXXXXX.com<mailto:1111111@kamprod.telemessage.com>>;tag=64H63g861ajHj Call-ID: Sq4jR85o3Caz2XTXo-71FKAdbJ1x9vz2 CSeq: 8107 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: ti PJSIP responds with: Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session What is the reason for this? How can I fix this issue? Thanks, Arik Halperin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com/> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio World Conference -- www.kamailioworld.com<http://www.kamailioworld.com/>

Daniel-Constantin Mierla

10:32 a.m.

Hello, can you paste here the 200OK for INVITE sent out by kamailio and the ACK received by kamailio? Cheers, Daniel On 11.06.18 09:51, Arik Halperin wrote:

...

On 11 Jun 2018, at 9:43, Daniel-Constantin Mierla <miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: Hello, Kamailio is not involved in the issue reported here. Practically, pjsip expects sips: scheme in the contact URI, which was set by FreeSwitch in 200ok. Maybe there is an option that you have to turn on for FreeSwitch to use sips: scheme. Otherwise, you can try to replace sip with sips in kamailio config and do the reverse the other way. Cheers, Daniel On 05.06.18 06:56, Arik Halperin wrote:

Hello, I’m using TLS After receiving 200OK from kamailio: r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP: (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS 70.36.25.65:443: SIP/2.0 200 OK Via: SIP/2.0/TLS 10.134.232.109:44097;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB-Qh78PmIQFrRk;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> From: "number" <sips:972523391991@XXXXXXX.com <mailto:972523391991@kamprod.telemessage.com>>;tag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO To: <sips:1111111@XXXXXX.com <mailto:1111111@kamprod.telemessage.com>>;tag=64H63g861ajHj Call-ID: Sq4jR85o3Caz2XTXo-71FKAdbJ1x9vz2 CSeq: 8107 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: ti *PJSIP responds with:* * * *Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session* * * What is the reason for this? How can I fix this issue? Thanks, Arik Halperin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com

Arik Halperin

12:58 p.m.

Daniel Hello, Pasted below, 200 OK and Following ACK(Recorded at the client side via wireshark configured with private key) BR, Arik Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/TLS 192.168.2.2:48182;received=82.80.164.63;rport=33898;branch=z9hG4bKPjVppvYKQb4X5lJrYpod1wUN.j3KVLrEiT;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;ftag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> From: "number" <sips:17813000000@XXXXXX.com<mailto:17813000000@XXXXXX.com>>;tag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF To: <sips:1111111@XXXXXX.com<mailto:1111111@XXXXXX.com>>;tag=7t2StmvUeNpQD Call-ID: yekcL-0b2PhpgdQo52l921tjX1Z8wErH CSeq: 10885 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Session-Expires: 1800;refresher=uac Content-Type: application/sdp Content-Disposition: session Content-Length: 1056 Remote-Party-ID: "1111111" <sip:1111111@XXXXXX.com>;party=calling;privacy=off;screen=no Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): FreeSWITCH 1528683321 1528683322 IN IP4 70.36.25.66 Session Name (s): FreeSWITCH Connection Information (c): IN IP4 70.36.25.66 Time Description, active time (t): 0 0 Session Attribute (a): msid-semantic: WMS V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K Media Description, name and address (m): audio 37680 RTP/SAVP 107 96 Media Attribute (a): ice-ufrag:b6TC1SdbiQd6k5GL Media Attribute (a): ice-pwd:NtGGa3jbPjvwRLASIklz2oAa Media Attribute (a): candidate:5807878115 1 udp 659136 10.168.10.200 38056 typ host generation 0 Media Attribute (a): candidate:5807878115 2 udp 659135 10.168.10.200 38057 typ host generation 0 Media Attribute (a): ssrc:3542382753 cname:ASW42RxMaWauQHpe Media Attribute (a): ssrc:3542382753 msid:V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K a0 Media Attribute (a): ssrc:3542382753 mslabel:V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K Media Attribute (a): ssrc:3542382753 label:V60mDk4CUtzxt4H5xDQPB48KjzMcYE1Ka0 Media Attribute (a): rtpmap:107 opus/48000/2 Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:107 useinbandfec=1; minptime=10; maxptime=40 Media Attribute (a): fmtp:96 0-16 Media Attribute (a): sendrecv Media Attribute (a): rtcp:37681 Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/KCNveJuRh5lQ+g3YWnyb2QwQhl0GgdmxtKAJ5G3 Media Attribute (a): ptime:20 Media Attribute (a): candidate:K6gXQsPK0KD4MsGa 1 UDP 2130706431 70.36.25.66 37680 typ host Media Attribute (a): candidate:K6gXQsPK0KD4MsGa 2 UDP 2130706430 70.36.25.66 37681 typ host Media Attribute (a): end-of-candidates 1201 272.987349 192.168.2.2 70.36.25.65 SIP 695 Request: ACK sip:1111111@10.168.10.200:5080;transport=tls | 1201 Frame 1201: 695 bytes on wire (5560 bits), 695 bytes captured (5560 bits) on interface 0 Ethernet II, Src: Htc_50:62:7b (ac:37:43:50:62:7b), Dst: 9a:01:a7:d9:66:64 (9a:01:a7:d9:66:64) Internet Protocol Version 4, Src: 192.168.2.2, Dst: 70.36.25.65 Transmission Control Protocol, Src Port: 48182, Dst Port: 443, Seq: 8791, Ack: 10303, Len: 629 Secure Sockets Layer Session Initiation Protocol (ACK) Request-Line: ACK sip:1111111@10.168.10.200:5080;transport=tls SIP/2.0 Message Header Via: SIP/2.0/TLS 192.168.2.2:48182;rport;branch=z9hG4bKPjFpv1IqHt9ON8nS6zOYuUZ5HxhNTDTBq7;alias Max-Forwards: 70 From: "number" <sips:17813000000@XXXXXXXX.com<mailto:17813000000@XXXXXXXX.com>>;tag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF To: sips:1111111@XXXXXXX.com<mailto:1111111@XXXXXXX.com>;tag=7t2StmvUeNpQD Call-ID: yekcL-0b2PhpgdQo52l921tjX1Z8wErH CSeq: 10885 ACK Route: <sips:70.36.25.65:443;transport=tls;lr;r2=on;ftag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> Route: <sips:10.168.10.227:5099;lr;r2=on;ftag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> Content-Length: 0 On 11 Jun 2018, at 13:32, Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: Hello, can you paste here the 200OK for INVITE sent out by kamailio and the ACK received by kamailio? Cheers, Daniel On 11.06.18 09:51, Arik Halperin wrote: Daniel, Thank you! You are right about this. I configured PJSIP not to check whether the contact contains SIPS. This solved the problem on one of my setups where I have one NIC that has a public IP. However on the original setup, the kamailio has one public IP and one private IP. In that setup, the ACK to the 200 OK is not forwarded over the private IP to the freeswitch. This only happens in TLS, when I work with TCP it works well. I believe it is somehow connected to the record route, and I’m looking into PJSIP to try to find the answer, but is there anything I could do in the kamailio? I have the same problems with other SIP clients(Bria for example) Thanks, Arik Halperin On 11 Jun 2018, at 9:43, Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: Hello, Kamailio is not involved in the issue reported here. Practically, pjsip expects sips: scheme in the contact URI, which was set by FreeSwitch in 200ok. Maybe there is an option that you have to turn on for FreeSwitch to use sips: scheme. Otherwise, you can try to replace sip with sips in kamailio config and do the reverse the other way. Cheers, Daniel On 05.06.18 06:56, Arik Halperin wrote: Hello, I’m using TLS After receiving 200OK from kamailio: r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP: (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS 70.36.25.65:443: SIP/2.0 200 OK Via: SIP/2.0/TLS 10.134.232.109:44097;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB-Qh78PmIQFrRk;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> From: "number" <sips:972523391991@XXXXXXX.com<mailto:972523391991@kamprod.telemessage.com>>;tag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO To: <sips:1111111@XXXXXX.com<mailto:1111111@kamprod.telemessage.com>>;tag=64H63g861ajHj Call-ID: Sq4jR85o3Caz2XTXo-71FKAdbJ1x9vz2 CSeq: 8107 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: ti PJSIP responds with: Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session What is the reason for this? How can I fix this issue? Thanks, Arik Halperin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com/> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio World Conference -- www.kamailioworld.com<http://www.kamailioworld.com/> -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com/> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio World Conference -- www.kamailioworld.com<http://www.kamailioworld.com/>

Julien Chavanton

12 Jun 12 Jun

7:50 a.m.

Hi, the problem with SIPS URI scheme is not only about the Contact header but record-route and other headers. One option is to use TOPOS. You can find more information here: - PJSIP Ticket #1735: Check Contact/Record-Route header in a secure dialog. - https://issues.asterisk.org/jira/browse/ASTERISK-24646 <https://flowroute.atlassian.net/secure/AddComment%21default.jspa?id=19438> https://tools.ietf.org/html/rfc5630#section-3.2 3.2. Detection of Hop-by-Hop Security The presence of a SIPS Request-URI does not necessarily indicate that the request was sent securely on each hop. So how does a UAS know if SIPS was used for the entire request path to secure the request end- to-end? Effectively, the UAS cannot know for sure. However, [RFC3261], Section 26.4.4, recommends how a UAS can make some checks to validate the security. Additionally, the History-Info header field [RFC4244] could be inspected for detecting retargeting from SIP and SIPS. Retargeting from SIP to SIPS by a proxy is an issue because it can leave the receiver of the request with the impression that the request was delivered securely on each hop, while in fact, it was not. On Mon, Jun 11, 2018 at 5:58 AM, Arik Halperin <arik(a)mobilinq.io> wrote:

...

Daniel Hello, Pasted below, 200 OK and Following ACK(Recorded at the client side via wireshark configured with private key) BR, Arik Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/TLS 192.168.2.2:48182;received=82. 80.164.63;rport=33898;branch=z9hG4bKPjVppvYKQb4X5lJrYpod1wU N.j3KVLrEiT;alias Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag= ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on; ftag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> From: "number" <sips:17813000000@XXXXXX.com>;tag= ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF To: <sips:1111111@XXXXXX.com>;tag=7t2StmvUeNpQD Call-ID: yekcL-0b2PhpgdQo52l921tjX1Z8wErH CSeq: 10885 INVITE Contact: <sip:1111111@10.168.10.200:5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~ 987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Session-Expires: 1800;refresher=uac Content-Type: application/sdp Content-Disposition: session Content-Length: 1056 Remote-Party-ID: "1111111" <sip:1111111@XXXXXX.com>; party=calling;privacy=off;screen=no Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): FreeSWITCH 1528683321 1528683322 IN IP4 70.36.25.66 Session Name (s): FreeSWITCH Connection Information (c): IN IP4 70.36.25.66 Time Description, active time (t): 0 0 Session Attribute (a): msid-semantic: WMS V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K Media Description, name and address (m): audio 37680 RTP/SAVP 107 96 Media Attribute (a): ice-ufrag:b6TC1SdbiQd6k5GL Media Attribute (a): ice-pwd:NtGGa3jbPjvwRLASIklz2oAa Media Attribute (a): candidate:5807878115 1 udp 659136 10.168.10.200 38056 typ host generation 0 Media Attribute (a): candidate:5807878115 2 udp 659135 10.168.10.200 38057 typ host generation 0 Media Attribute (a): ssrc:3542382753 cname:ASW42RxMaWauQHpe Media Attribute (a): ssrc:3542382753 msid: V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K a0 Media Attribute (a): ssrc:3542382753 mslabel: V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K Media Attribute (a): ssrc:3542382753 label: V60mDk4CUtzxt4H5xDQPB48KjzMcYE1Ka0 Media Attribute (a): rtpmap:107 opus/48000/2 Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:107 useinbandfec=1; minptime=10; maxptime=40 Media Attribute (a): fmtp:96 0-16 Media Attribute (a): sendrecv Media Attribute (a): rtcp:37681 Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/KCNveJuRh5lQ+g3YWnyb2QwQhl0GgdmxtKAJ5G3 Media Attribute (a): ptime:20 Media Attribute (a): candidate:K6gXQsPK0KD4MsGa 1 UDP 2130706431 70.36.25.66 37680 typ host Media Attribute (a): candidate:K6gXQsPK0KD4MsGa 2 UDP 2130706430 70.36.25.66 37681 typ host Media Attribute (a): end-of-candidates 1201 272.987349 192.168.2.2 70.36.25.65 SIP 695 Request: ACK sip:1111111@10.168.10.200:5080;transport=tls | 1201 Frame 1201: 695 bytes on wire (5560 bits), 695 bytes captured (5560 bits) on interface 0 Ethernet II, Src: Htc_50:62:7b (ac:37:43:50:62:7b), Dst: 9a:01:a7:d9:66:64 (9a:01:a7:d9:66:64) Internet Protocol Version 4, Src: 192.168.2.2, Dst: 70.36.25.65 Transmission Control Protocol, Src Port: 48182, Dst Port: 443, Seq: 8791, Ack: 10303, Len: 629 Secure Sockets Layer Session Initiation Protocol (ACK) Request-Line: ACK sip:1111111@10.168.10.200:5080;transport=tls SIP/2.0 Message Header Via: SIP/2.0/TLS 192.168.2.2:48182;rport;branch= z9hG4bKPjFpv1IqHt9ON8nS6zOYuUZ5HxhNTDTBq7;alias Max-Forwards: 70 From: "number" <sips:17813000000@XXXXXXXX.com>;tag= ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF To: sips:1111111@XXXXXXX.com;tag=7t2StmvUeNpQD Call-ID: yekcL-0b2PhpgdQo52l921tjX1Z8wErH CSeq: 10885 ACK Route: <sips:70.36.25.65:443;transport=tls;lr;r2=on;ftag= ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> Route: <sips:10.168.10.227:5099;lr;r2=on;ftag= ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes> Content-Length: 0 On 11 Jun 2018, at 13:32, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: Hello, can you paste here the 200OK for INVITE sent out by kamailio and the ACK received by kamailio? Cheers, Daniel On 11.06.18 09:51, Arik Halperin wrote: Daniel, Thank you! You are right about this. I configured PJSIP not to check whether the contact contains SIPS. This solved the problem on one of my setups where I have one NIC that has a public IP. However on the original setup, the kamailio has one public IP and one private IP. In that setup, the ACK to the 200 OK is not forwarded over the private IP to the freeswitch. This only happens in TLS, when I work with TCP it works well. I believe it is somehow connected to the record route, and I’m looking into PJSIP to try to find the answer, but is there anything I could do in the kamailio? I have the same problems with other SIP clients(Bria for example) Thanks, Arik Halperin On 11 Jun 2018, at 9:43, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: Hello, Kamailio is not involved in the issue reported here. Practically, pjsip expects sips: scheme in the contact URI, which was set by FreeSwitch in 200ok. Maybe there is an option that you have to turn on for FreeSwitch to use sips: scheme. Otherwise, you can try to replace sip with sips in kamailio config and do the reverse the other way. Cheers, Daniel On 05.06.18 06:56, Arik Halperin wrote: Hello, I’m using TLS After receiving 200OK from kamailio: r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP: (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS 70.36.25.65:443: SIP/2.0 200 OK Via: SIP/2.0/TLS 10.134.232.109:44097 ;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB- Qh78PmIQFrRk;alias Record-Route: <sips:10.168.10.227:5099 ;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> Record-Route: <sips:70.36.25.65:443; transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes> From: "number" <sips: 972523391991(a)XXXXXXX.com <972523391991(a)kamprod.telemessage.com>>;tag= mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO To: <sips:1111111@XXXXXX.com <1111111(a)kamprod.telemessage.com>>;tag=64H63g861ajHj Call-ID: Sq4jR85o3Caz2XTXo- 71FKAdbJ1x9vz2 CSeq: 8107 INVITE Contact: <sip:1111111@10.168.10.200: 5080;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: ti *PJSIP responds with:* *Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session* What is the reason for this? How can I fix this issue? Thanks, Arik Halperin _______________________________________________ Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2410

days inactive

2417

days old

sr-users@lists.kamailio.org

Manage subscription

5 comments

3 participants

tags (0)

participants (3)

Arik Halperin
Daniel-Constantin Mierla
Julien Chavanton