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

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


_________________________________________________________________________
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