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