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