For controlling DTLS, this could come in handy: https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables#ChannelVariables-rtp_secure_media

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


_________________________________________________________________________
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