Encryption modes on legs influencing each other
FS is a B2BUA. However, the two legs of a regular call seem to influence each other, e.g. 1. The caller offers an SDES-SRTP-encrypted connection with ICE. 2. FS offers to the callee a simple RTP connection (no SRTP, no ICE, as configured in the dialplan), callee answers respectively. 3. FS answers caller, but without with neither "a:crypto" entries nor ICE candidates. 4. Why is that? Shouldn't it answer SDES-SRTP with ICE to the original caller, respecting the original caller's offer? When doing WebRTC from the caller (DTLS-SRTP with ICE), this actually works fine (callee unchanged). So what's the general scheme for choosing encryption on either side? Related to that: Can you enable ICE without completely enabling WebRTC (media_webrtc=true) from the dialplan? That would help maybe... -- Johannes Singler Software Engineer Qnective
Even when calling the echo call service, it does not work. To be more specific: How can I make FS respond to this SDP v=0 o=- 7827925660507220020 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS ARDAMS m=audio 9 RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126 c=IN IP4 0.0.0.0 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:9 G722/8000 a=rtpmap:102 ILBC/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:127 red/8000 a=rtpmap:126 telephone-event/8000 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:MDEFXaTwID0Qv/el a=ice-pwd:oj31a5bRhExyyehlEKTAVFw1 a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=rtcp-mux a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:iMD5gSrO/mnMCNTcp3k85tMS3P4NgXf6wFubAmZW a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:iMD5gSrO/mnMCNTcp3k85tMS3P4NgXf6wFubAmZW a=maxptime:60 a=ssrc:2184339687 cname:/TpRcJ+yclk4xBm4 a=ssrc:2184339687 msid:ARDAMS ARDAMSa0 a=ssrc:2184339687 mslabel:ARDAMS a=ssrc:2184339687 label:ARDAMSa0 a=candidate:4203996854 1 udp 2122260223 10.110.44.92 46241 typ host generation 0 with something compatible, i.e. something having ice-ufrag/ice-pwd/candidate, and crypto entries? Instead, it responds with this incomplete SDP: v=0 o=FreeSWITCH 1444208399 1444208400 IN IP4 10.110.36.194 s=FreeSWITCH c=IN IP4 10.110.36.194 t=0 0 a=sendonly a=msid-semantic: WMS hotZDrIQsyNJstePWz1e1QRgqVxi8lkg m=audio 19770 RTP/AVPF 111 126 Some additional lines are printed on the FS log, but they don't seem to make it on the network (according to WireShark) a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10 a=rtpmap:126 telephone-event/8000 a=ptime:20 a=rtcp-mux a=rtcp:19770 IN IP4 10.110.36.194 a=ice-ufrag:hSw9zdfPZDYYO94d a=ice-pwd:D05puFtnS7zoQqGY83Yx73dW a=candidate:5758928345 1 udp 659136 10.110.36.194 19770 typ host generation 0 a=ssrc:2316904761 cname:zE52VDJe2mOlFS0s a=ssrc:2316904761 msid:hotZDrIQsyNJstePWz1e1QRgqVxi8lkg a0 a=ssrc:2316904761 mslabel:hotZDrIQsyNJstePWz1e1QRgqVxi8lkg a=ssrc:2316904761 label:hotZDrIQsyNJstePWz1e1QRgqVxi8lkga0 Total packet length is 1138 bytes... On Mon, Oct 5, 2015 at 4:51 PM, Johannes Singler < johannes.singler@qnective.com> wrote:
FS is a B2BUA. However, the two legs of a regular call seem to influence each other, e.g.
1. The caller offers an SDES-SRTP-encrypted connection with ICE. 2. FS offers to the callee a simple RTP connection (no SRTP, no ICE, as configured in the dialplan), callee answers respectively. 3. FS answers caller, but without with neither "a:crypto" entries nor ICE candidates. 4. Why is that? Shouldn't it answer SDES-SRTP with ICE to the original caller, respecting the original caller's offer?
When doing WebRTC from the caller (DTLS-SRTP with ICE), this actually works fine (callee unchanged).
So what's the general scheme for choosing encryption on either side?
Related to that: Can you enable ICE without completely enabling WebRTC (media_webrtc=true) from the dialplan? That would help maybe...
-- Johannes Singler Software Engineer
Qnective
-- Johannes Singler Software Engineer Qnective Thurgauerstrasse 54 | 8050 Zürich | Switzerland Mobile +41798379869 www.qnective.com | johannes.singler@qnective.com
For controlling DTLS, this could come in handy: https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables#Chann... Turn on sip tracing in the console with "sofia global siptrace on", might need to increase the log level, too. It will show you exactly what FS is sending, assuming you are using SIP. If that still differs from what you see on the wire, it could be a fragmentation issue, though the SDP seems to short for that. Maybe there's a lot of clutter in the headers already, or your network uses a low MTU. Try TCP signalling to rule that out. And make sure you use latest master. On 10/07/2015 11:33 AM, Johannes Singler wrote:
Even when calling the echo call service, it does not work. To be more specific: How can I make FS respond to this SDP
v=0 o=- 7827925660507220020 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS ARDAMS m=audio 9 RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126 c=IN IP4 0.0.0.0 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:9 G722/8000 a=rtpmap:102 ILBC/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:127 red/8000 a=rtpmap:126 telephone-event/8000 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:MDEFXaTwID0Qv/el a=ice-pwd:oj31a5bRhExyyehlEKTAVFw1 a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=rtcp-mux a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:iMD5gSrO/mnMCNTcp3k85tMS3P4NgXf6wFubAmZW a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:iMD5gSrO/mnMCNTcp3k85tMS3P4NgXf6wFubAmZW a=maxptime:60 a=ssrc:2184339687 cname:/TpRcJ+yclk4xBm4 a=ssrc:2184339687 msid:ARDAMS ARDAMSa0 a=ssrc:2184339687 mslabel:ARDAMS a=ssrc:2184339687 label:ARDAMSa0 a=candidate:4203996854 1 udp 2122260223 10.110.44.92 46241 typ host generation 0
with something compatible, i.e. something having ice-ufrag/ice-pwd/candidate, and crypto entries?
Instead, it responds with this incomplete SDP:
v=0 o=FreeSWITCH 1444208399 1444208400 IN IP4 10.110.36.194 s=FreeSWITCH c=IN IP4 10.110.36.194 t=0 0 a=sendonly a=msid-semantic: WMS hotZDrIQsyNJstePWz1e1QRgqVxi8lkg m=audio 19770 RTP/AVPF 111 126
Some additional lines are printed on the FS log, but they don't seem to make it on the network (according to WireShark)
a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10 a=rtpmap:126 telephone-event/8000 a=ptime:20 a=rtcp-mux a=rtcp:19770 IN IP4 10.110.36.194 a=ice-ufrag:hSw9zdfPZDYYO94d a=ice-pwd:D05puFtnS7zoQqGY83Yx73dW a=candidate:5758928345 1 udp 659136 10.110.36.194 19770 typ host generation 0 a=ssrc:2316904761 cname:zE52VDJe2mOlFS0s a=ssrc:2316904761 msid:hotZDrIQsyNJstePWz1e1QRgqVxi8lkg a0 a=ssrc:2316904761 mslabel:hotZDrIQsyNJstePWz1e1QRgqVxi8lkg a=ssrc:2316904761 label:hotZDrIQsyNJstePWz1e1QRgqVxi8lkga0
Total packet length is 1138 bytes...
On Mon, Oct 5, 2015 at 4:51 PM, Johannes Singler <johannes.singler@qnective.com <mailto:johannes.singler@qnective.com>> wrote:
FS is a B2BUA. However, the two legs of a regular call seem to influence each other, e.g.
1. The caller offers an SDES-SRTP-encrypted connection with ICE. 2. FS offers to the callee a simple RTP connection (no SRTP, no ICE, as configured in the dialplan), callee answers respectively. 3. FS answers caller, but without with neither "a:crypto" entries nor ICE candidates. 4. Why is that? Shouldn't it answer SDES-SRTP with ICE to the original caller, respecting the original caller's offer?
When doing WebRTC from the caller (DTLS-SRTP with ICE), this actually works fine (callee unchanged).
So what's the general scheme for choosing encryption on either side?
Related to that: Can you enable ICE without completely enabling WebRTC (media_webrtc=true) from the dialplan? That would help maybe...
-- Johannes Singler Software Engineer
Qnective
-- Johannes Singler Software Engineer
Qnective
Thurgauerstrasse 54 | 8050 Zürich | Switzerland Mobile +41798379869 www.qnective.com <http://www.qnective.com/> | johannes.singler@qnective.com <mailto:johannes.singler@qnective.com>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
On Wed, Oct 7, 2015 at 8:11 PM, Thomas Auge <lists@virtues.net> wrote:
For controlling DTLS, this could come in handy: https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables#Chann...
Turn on sip tracing in the console with "sofia global siptrace on", might need to increase the log level, too. It will show you exactly what FS is sending, assuming you are using SIP.
Okay, so now I get 2015-10-08 15:31:21.967585 [DEBUG] mod_sofia.c:799 Local SDP sofia/internal/ 1005@10.110.36.194:5060: v=0 o=FreeSWITCH 1444290677 1444290678 IN IP4 10.110.36.194 s=FreeSWITCH c=IN IP4 10.110.36.194 t=0 0 a=sendonly a=msid-semantic: WMS 0jji44liYAamTxDhFANoV40s2VSqaq70 m=audio 27604 RTP/AVPF 111 126 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10 a=rtpmap:126 telephone-event/8000 a=ptime:20 a=rtcp-mux a=rtcp:27604 IN IP4 10.110.36.194 a=ice-ufrag:6fKS9Ab1mTimagdz a=ice-pwd:ndUoomeZPhjFNK1KPCsP2tHe a=candidate:2643414560 1 udp 659136 10.110.36.194 27604 typ host generation 0 a=ssrc:2182785577 cname:zg9ublC0LCcu0GBv a=ssrc:2182785577 msid:0jji44liYAamTxDhFANoV40s2VSqaq70 a0 a=ssrc:2182785577 mslabel:0jji44liYAamTxDhFANoV40s2VSqaq70 a=ssrc:2182785577 label:0jji44liYAamTxDhFANoV40s2VSqaq70a0 send 1094 bytes to udp/[10.110.36.27]:5060 at 15:31:21.983975: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 10.110.36.27;branch=z9hG4bKN82reFjQ2rZmQ From: <sip:1005@10.110.36.194:5060>;tag=QS5Na83Q2g2gj To: <sip:9196@10.110.36.194:5060>;tag=8U51K76U4yB1N Call-ID: 783bfcc8-e874-1233-e0b3-989096a9db3a CSeq: 913303564 INVITE Contact: <sip:9196@10.110.36.194:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.7.0+git~20151008T014056Z~d1fca9bd31~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 198 Remote-Party-ID: "9196" <sip:9196@10.110.36.194
;party=calling;privacy=off;screen=no
v=0 o=FreeSWITCH 1444290677 1444290678 IN IP4 10.110.36.194 s=FreeSWITCH c=IN IP4 10.110.36.194 t=0 0 a=sendonly a=msid-semantic: WMS 0jji44liYAamTxDhFANoV40s2VSqaq70 m=audio 0 RTP/SAVPF 19 So indeed, the SDP that is sent is different from the "Local SDP" logged before. What could be the reason for this behavior? The "sendonly" flag maybe? Why is that one set? In the code, logging that "Local SDP" and handing it over to Sofia for sending seems just a few lines apart (line 799 and 852 in mod_sofia.c).
If that still differs from what you see on the wire, it could be a fragmentation issue, though the SDP seems to short for that. Maybe there's a lot of clutter in the headers already, or your network uses a low MTU. Try TCP signalling to rule that out.
So I don't think fragmentation is the issue.
And make sure you use latest master.
I did.
On 10/07/2015 11:33 AM, Johannes Singler wrote:
Even when calling the echo call service, it does not work. To be more specific: How can I make FS respond to this SDP
v=0 o=- 7827925660507220020 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS ARDAMS m=audio 9 RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126 c=IN IP4 0.0.0.0 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:9 G722/8000 a=rtpmap:102 ILBC/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:127 red/8000 a=rtpmap:126 telephone-event/8000 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:MDEFXaTwID0Qv/el a=ice-pwd:oj31a5bRhExyyehlEKTAVFw1 a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=rtcp-mux a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:iMD5gSrO/mnMCNTcp3k85tMS3P4NgXf6wFubAmZW a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:iMD5gSrO/mnMCNTcp3k85tMS3P4NgXf6wFubAmZW a=maxptime:60 a=ssrc:2184339687 cname:/TpRcJ+yclk4xBm4 a=ssrc:2184339687 msid:ARDAMS ARDAMSa0 a=ssrc:2184339687 mslabel:ARDAMS a=ssrc:2184339687 label:ARDAMSa0 a=candidate:4203996854 1 udp 2122260223 10.110.44.92 46241 typ host generation 0
with something compatible, i.e. something having ice-ufrag/ice-pwd/candidate, and crypto entries?
Instead, it responds with this incomplete SDP:
v=0 o=FreeSWITCH 1444208399 1444208400 IN IP4 10.110.36.194 s=FreeSWITCH c=IN IP4 10.110.36.194 t=0 0 a=sendonly a=msid-semantic: WMS hotZDrIQsyNJstePWz1e1QRgqVxi8lkg m=audio 19770 RTP/AVPF 111 126
Some additional lines are printed on the FS log, but they don't seem to make it on the network (according to WireShark)
a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10 a=rtpmap:126 telephone-event/8000 a=ptime:20 a=rtcp-mux a=rtcp:19770 IN IP4 10.110.36.194 a=ice-ufrag:hSw9zdfPZDYYO94d a=ice-pwd:D05puFtnS7zoQqGY83Yx73dW a=candidate:5758928345 1 udp 659136 10.110.36.194 19770 typ host generation 0 a=ssrc:2316904761 cname:zE52VDJe2mOlFS0s a=ssrc:2316904761 msid:hotZDrIQsyNJstePWz1e1QRgqVxi8lkg a0 a=ssrc:2316904761 mslabel:hotZDrIQsyNJstePWz1e1QRgqVxi8lkg a=ssrc:2316904761 label:hotZDrIQsyNJstePWz1e1QRgqVxi8lkga0
Total packet length is 1138 bytes...
On Mon, Oct 5, 2015 at 4:51 PM, Johannes Singler < <johannes.singler@qnective.com>johannes.singler@qnective.com> wrote:
FS is a B2BUA. However, the two legs of a regular call seem to influence each other, e.g.
1. The caller offers an SDES-SRTP-encrypted connection with ICE. 2. FS offers to the callee a simple RTP connection (no SRTP, no ICE, as configured in the dialplan), callee answers respectively. 3. FS answers caller, but without with neither "a:crypto" entries nor ICE candidates. 4. Why is that? Shouldn't it answer SDES-SRTP with ICE to the original caller, respecting the original caller's offer?
When doing WebRTC from the caller (DTLS-SRTP with ICE), this actually works fine (callee unchanged).
So what's the general scheme for choosing encryption on either side?
Related to that: Can you enable ICE without completely enabling WebRTC (media_webrtc=true) from the dialplan? That would help maybe...
-- Johannes Singler Software Engineer
Qnective
-- Johannes Singler Software Engineer
Qnective
Thurgauerstrasse 54 | 8050 Zürich | Switzerland Mobile +41798379869 www.qnective.com | <johannes.singler@qnective.com> johannes.singler@qnective.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Johannes Singler Software Engineer Qnective
participants (2)
-
Johannes Singler
-
Thomas Auge