Hello all, I'm trying to deploy FreeSWITCH as a back-end for Opensips ( http://wiki.freeswitch.org/wiki/Opensips ). TLS -> Opensips -> UDP -> FreeSWITCH TLS work fine end point is registered. But when call phone FreeSWITCH send invite use TLS instead of UDP. Register exsample: 172.20.0.24 - opensips 172.20.0.22 - freeswitch 172.20.0.20 - phone REGISTER sip:172.20.0.22:5060 SIP/2.0 Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK3641.9fabd823.0;i=15 Via: SIP/2.0/TLS 172.20.0.20:5060;received=172.20.0.20;branch=z9hG4bK1590064540;rport=47050;alias From: <sip:1001@172.20.0.24:5061>;tag=1518243149 To: <sip:1001@172.20.0.24:5061> Call-ID: 1616382919-5060-1@BHC.CA.A.CA CSeq: 2505 REGISTER Contact: <sip:1001@172.20.0.20:5060;transport=tls>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B823DB6B2>" Authorization: Digest username="1001", realm="172.20.0.24", nonce="102dacd4-959f-11e2-8317-67a135a6f66b", uri="sip:172.20.0.24:5061", response="8f80bc7f8fb5fe5a895a5b39f9b5cde6", algorithm=MD5, cnonce="12386720", qop=auth, nc=00000005 Max-Forwards: 30 User-Agent: Grandstream GXP1405 1.0.5.10 Supported: path Expires: 300 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 Path: <sip:172.20.0.24;r2=on;lr;received=sip:172.20.0.20:47050> X-AUTH-IP: 172.20.0.20 Call-ID: 1616382919-5060-1@BHC.CA.A.CA User: 1001@172.20.0.22 Contact: "user" <sip:1001@172.20.0.20:5060;transport=tls;fs_path=%3Csip%3A172.20.0.24%3Br2%3Don%3Blr%3Breceived%3Dsip%3A172.20.0.20%3A47050%3E> Agent: Grandstream GXP1405 1.0.5.10 Status: Registered(TLS)(unknown) EXP(2013-03-26 01:01:18) EXPSECS(309) Host: 172.20.0.22 IP: 172.20.0.24 Port: 5060 Auth-User: 1001 Auth-Realm: 172.20.0.24 MWI-Account: 1001@172.20.0.22 sofia/internal/sip:1001@172.20.0.20:5060;transport=tls;fs_path=%3Csip%3A172.20.0.24%3Br2%3Don%3Blr%3Breceived%3Dsip%3A172.20.0.20%3A47050%3E I'm not familiar with C + + to test made small changes I understand it's not right but it works in src/mod/endpoints/mod_sofia/sofia_glue.c 1233, 1348 change } else if (!strncasecmp(str, "tls", 3)) { return SOFIA_TRANSPORT_TCP_TLS; } to } else if (!strncasecmp(str, "tls", 3)) { return SOFIA_TRANSPORT_UDP; } Can anyone tell how to configure FreeSWITCH for normal UDP->TLS TLS->UDP work. Or maybe I'm doing something wrong? Sorry for my english
I don't know much about OpenSIPS but it looks to me like OpenSIPS is specifically requesting to use TLS as the transport. The Contact header you showed specifically has "transport=tls". I know that OpenSIPS is quite a versatile proxy so it would not surprise me if it is able to do what you are wanting. I would ask on the OpenSIPS mailing list for tips on how to accomplish this. Bogan (creator of OpenSIPS) knows a lot about FreeSWITCH as well. If this can be done they'll be happy to show you how. If you figure it out please come back and tell us if you had to make changes to OpenSIPS config, FreeSWITCH config, or both. Thanks, Michael On Mon, Mar 25, 2013 at 4:03 PM, Chusov Alexsander < chusov.alexsandr@gmail.com> wrote:
Hello all,
I'm trying to deploy FreeSWITCH as a back-end for Opensips ( http://wiki.freeswitch.org/wiki/Opensips ). TLS -> Opensips -> UDP -> FreeSWITCH TLS work fine end point is registered. But when call phone FreeSWITCH send invite use TLS instead of UDP.
Register exsample: 172.20.0.24 - opensips 172.20.0.22 - freeswitch 172.20.0.20 - phone
REGISTER sip:172.20.0.22:5060 SIP/2.0 Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK3641.9fabd823.0;i=15 Via: SIP/2.0/TLS 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK1590064540;rport=47050;alias From: <sip:1001@172.20.0.24:5061>;tag=1518243149 To: <sip:1001@172.20.0.24:5061> Call-ID: 1616382919-5060-1@BHC.CA.A.CA CSeq: 2505 REGISTER Contact: <sip:1001@172.20.0.20:5060 ;transport=tls>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B823DB6B2>" Authorization: Digest username="1001", realm="172.20.0.24", nonce="102dacd4-959f-11e2-8317-67a135a6f66b", uri="sip:172.20.0.24:5061", response="8f80bc7f8fb5fe5a895a5b39f9b5cde6", algorithm=MD5, cnonce="12386720", qop=auth, nc=00000005 Max-Forwards: 30 User-Agent: Grandstream GXP1405 1.0.5.10 Supported: path Expires: 300 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 Path: <sip:172.20.0.24;r2=on;lr;received=sip:172.20.0.20:47050> X-AUTH-IP: 172.20.0.20
Call-ID: 1616382919-5060-1@BHC.CA.A.CA User: 1001@172.20.0.22 Contact: "user" <sip:1001@172.20.0.20:5060 ;transport=tls;fs_path=%3Csip%3A172.20.0.24%3Br2%3Don%3Blr%3Breceived%3Dsip%3A172.20.0.20%3A47050%3E> Agent: Grandstream GXP1405 1.0.5.10 Status: Registered(TLS)(unknown) EXP(2013-03-26 01:01:18) EXPSECS(309) Host: 172.20.0.22 IP: 172.20.0.24 Port: 5060 Auth-User: 1001 Auth-Realm: 172.20.0.24 MWI-Account: 1001@172.20.0.22
sofia/internal/sip:1001@172.20.0.20:5060 ;transport=tls;fs_path=%3Csip%3A172.20.0.24%3Br2%3Don%3Blr%3Breceived%3Dsip%3A172.20.0.20%3A47050%3E
I'm not familiar with C + + to test made small changes I understand it's not right but it works in src/mod/endpoints/mod_sofia/sofia_glue.c 1233, 1348 change
} else if (!strncasecmp(str, "tls", 3)) { return SOFIA_TRANSPORT_TCP_TLS; }
to } else if (!strncasecmp(str, "tls", 3)) { return SOFIA_TRANSPORT_UDP; }
Can anyone tell how to configure FreeSWITCH for normal UDP->TLS TLS->UDP work. Or maybe I'm doing something wrong?
Sorry for my english
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
2013/3/26 Michael Collins <msc@freeswitch.org>
showed specifically has "transport=tls
I wrote in the mailing list Bogan response: Hi Alexsandr, Well, the problem is more complex a bit. I see you configured OpenSIPs to add PATH header to REGISTER before sending it to FS. The address in PATH has UDP transport, so FS (if supports PATH) should send the calls back to OpenSIPS by using the address from PATH (with UDP). The contact in register has TLS transport (and you fwd it to FS as it is), but it should not be used directly by FS because of the presence and priority of PATH hdr. So, my only explanation is that FS does not support / not configured to handle PATH, so that it uses the address from contact, which is TLS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
For test replace FreeSWITCH witch Opensips for register. Phone -> TLS -> Opensips - > UDP -> Opensips Work fine. 172.20.0.24.5060 > 172.20.0.22.5060: [udp sum ok] SIP, length: 919 REGISTER sip:172.20.0.22:5060 SIP/2.0 Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK4529.c9ec9a7.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK512348322;rport=5060 From: <sip:1001@172.20.0.24>;tag=319008323 To: <sip:1001@172.20.0.24> Call-ID: 1014532685-5060-1@BHC.CA.A.CA CSeq: 2011 REGISTER Contact: <sip:1001@172.20.0.20:5060
;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B823DB6B2>" Authorization: Digest username="1001", realm="172.20.0.24", nonce="51533e2a000000218d8794b71cd2825d45bcad006b247f2a", uri="sip:172.20.0.24", response="b18f3fbbede44642c33564bffce9c1ea", algorithm=MD5 Max-Forwards: 30 User-Agent: Grandstream GXP1405 1.0.5.10 Supported: path Expires: 300 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 Path: <sip:172.20.0.24;lr;received=sip:172.20.0.20:5060> X-AUTH-IP: 172.20.0.20
172.20.0.22.5060 > 172.20.0.24.5060: [bad udp cksum 16dc!] SIP, length: 517 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK4529.c9ec9a7.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK512348322;rport=5060 From: <sip:1001@172.20.0.24>;tag=319008323 To: <sip:1001@172.20.0.24>;tag=64e8f587865022a9970237a3f630ac12.72d7 Call-ID: 1014532685-5060-1@BHC.CA.A.CA CSeq: 2011 REGISTER Contact: <sip:1001@172.20.0.20:5060>;expires=300 Path: <sip:172.20.0.24;lr;received=sip:172.20.0.20:5060> Server: OpenSIPS (1.9.0-notls (x86_64/linux)) Content-Length: 0 Call from 1000 to 1001 172.20.0.24.5060 > 172.20.0.22.5060: [udp sum ok] SIP, length: 1223 INVITE sip:1000@172.20.0.22:5060 SIP/2.0 Record-Route: <sip:172.20.0.24;lr;ftag=256750377;did=a69.7eedcea5> Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK9cef.fef718b6.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK69130358;rport=5060 From: "1001" <sip:1001@172.20.0.24>;tag=256750377 To: <sip:1000@172.20.0.24> Call-ID: 1487412933-5060-4@BHC.CA.A.CA CSeq: 30 INVITE Contact: "1001" <sip:1001@172.20.0.20:5060> Max-Forwards: 30 User-Agent: Grandstream GXP1405 1.0.5.10 Privacy: none P-Preferred-Identity: "1001" <sip:1001@172.20.0.24> Supported: replaces, path, timer Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Type: application/sdp Accept: application/sdp, application/dtmf-relay Content-Length: 400 X-AUTH-IP: 172.20.0.20 v=0 o=1001 8000 8000 IN IP4 172.20.0.20 s=SIP Call c=IN IP4 172.20.0.20 t=0 0 m=audio 5004 RTP/AVP 0 8 4 18 9 97 2 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:9 G722/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=rtpmap:2 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 172.20.0.22.5060 > 172.20.0.24.5060: [bad udp cksum bb07!] SIP, length: 380 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK9cef.fef718b6.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK69130358;rport=5060 From: "1001" <sip:1001@172.20.0.24>;tag=256750377 To: <sip:1000@172.20.0.24> Call-ID: 1487412933-5060-4@BHC.CA.A.CA CSeq: 30 INVITE Server: OpenSIPS (1.9.0-notls (x86_64/linux)) Content-Length: 0 172.20.0.22.5060 > 172.20.0.24.5060: SIP, length: 1472 INVITE sip:1000@172.20.0.16:5060;transport=tls;transport=tls SIP/2.0 Record-Route: <sip:172.20.0.22;lr;did=a69.1fbc0244> Record-Route: <sip:172.20.0.24;lr;ftag=256750377;did=a69.7eedcea5> Via: SIP/2.0/UDP 172.20.0.22:5060;branch=z9hG4bK9cef.1674f7f1.0 Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK9cef.fef718b6.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK69130358;rport=5060 Route: <sip:172.20.0.24;r2=on;lr;received=sip:172.20.0.16:36572
,<sip:172.20.0.24:5061;transport=tls;r2=on;lr> From: "1001" <sip:1001@172.20.0.24>;tag=256750377 To: <sip:1000@172.20.0.24> Call-ID: 1487412933-5060-4@BHC.CA.A.CA CSeq: 30 INVITE Contact: "1001" <sip:1001@172.20.0.20:5060> Max-Forwards: 29 User-Agent: Grandstream GXP1405 1.0.5.10 Privacy: none P-Preferred-Identity: "1001" <sip:1001@172.20.0.24> Supported: replaces, path, timer Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Type: application/sdp Accept: application/sdp, application/dtmf-relay Content-Length: 400 X-AUTH-IP: 172.20.0.20
v=0 o=1001 8000 8000 IN IP4 172.20.0.20 s=SIP Call c=IN IP4 172.20.0.20 t=0 0 m=audio 5004 RTP/AVP 0 8 4 18 9 97 2 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:9 G722/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=rtpmap:2 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:[|sip] 172.20.0.24.5060 > 172.20.0.22.5060: [udp sum ok] SIP, length: 398 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 172.20.0.22:5060;branch=z9hG4bK9cef.1674f7f1.0 Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK9cef.fef718b6.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK69130358;rport=5060 From: "1001" <sip:1001@172.20.0.24>;tag=256750377 To: <sip:1000@172.20.0.24> Call-ID: 1487412933-5060-4@BHC.CA.A.CA CSeq: 30 INVITE Content-Length: 0 172.20.0.24.5060 > 172.20.0.22.5060: [udp sum ok] SIP, length: 942 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.20.0.22:5060;branch=z9hG4bK9cef.1674f7f1.0 Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK9cef.fef718b6.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK69130358;rport=5060 Record-Route: <sip:172.20.0.24:5061 ;transport=tls;r2=on;lr;ftag=256750377;did=a69.8eedcea5> Record-Route: <sip:172.20.0.24;r2=on;lr;ftag=256750377;did=a69.8eedcea5> Record-Route: <sip:172.20.0.22;lr;did=a69.1fbc0244> Record-Route: <sip:172.20.0.24;lr;ftag=256750377;did=a69.7eedcea5> From: "1001" <sip:1001@172.20.0.24>;tag=256750377 To: <sip:1000@172.20.0.24>;tag=1572316537 Call-ID: 1487412933-5060-4@BHC.CA.A.CA CSeq: 30 INVITE Contact: <sip:1000@172.20.0.16:36572;transport=tls> Supported: replaces, path, timer User-Agent: Grandstream GXP2120 1.0.5.14 Allow-Events: talk, hold Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 172.20.0.22.5060 > 172.20.0.24.5060: [bad udp cksum b82a!] SIP, length: 877 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.20.0.24;branch=z9hG4bK9cef.fef718b6.0 Via: SIP/2.0/UDP 172.20.0.20:5060 ;received=172.20.0.20;branch=z9hG4bK69130358;rport=5060 Record-Route: <sip:172.20.0.24:5061 ;transport=tls;r2=on;lr;ftag=256750377;did=a69.8eedcea5> Record-Route: <sip:172.20.0.24;r2=on;lr;ftag=256750377;did=a69.8eedcea5> Record-Route: <sip:172.20.0.22;lr;did=a69.1fbc0244> Record-Route: <sip:172.20.0.24;lr;ftag=256750377;did=a69.7eedcea5> From: "1001" <sip:1001@172.20.0.24>;tag=256750377 To: <sip:1000@172.20.0.24>;tag=1572316537 Call-ID: 1487412933-5060-4@BHC.CA.A.CA CSeq: 30 INVITE Contact: <sip:1000@172.20.0.16:36572;transport=tls> Supported: replaces, path, timer User-Agent: Grandstream GXP2120 1.0.5.14 Allow-Events: talk, hold Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 2013/3/26 Chusov Alexsandr <chusov.alexsandr@gmail.com>
2013/3/26 Michael Collins <msc@freeswitch.org>
showed specifically has "transport=tls
I wrote in the mailing list Bogan response:
Hi Alexsandr,
Well, the problem is more complex a bit. I see you configured OpenSIPs to add PATH header to REGISTER before sending it to FS. The address in PATH has UDP transport, so FS (if supports PATH) should send the calls back to OpenSIPS by using the address from PATH (with UDP). The contact in register has TLS transport (and you fwd it to FS as it is), but it should not be used directly by FS because of the presence and priority of PATH hdr.
So, my only explanation is that FS does not support / not configured to handle PATH, so that it uses the address from contact, which is TLS.
Regards,
Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
2013/3/27 Chusov Alexsandr <chusov.alexsandr@gmail.com>
Record-Route: <sip:172.20.0.22;lr;did=a69.1fbc0244> Record-Route: <sip:172.20.0.24;lr;ftag=256750377;did=a69.7eedcea5>
Sorry wrong sip trace http://pastebin.freeswitch.org/20733
participants (3)
-
Chusov Alexsander
-
Chusov Alexsandr
-
Michael Collins