[Freeswitch-users] Encryption modes on legs influencing each other

Thu Oct 8 19:35:31 MSD 2015

On Wed, Oct 7, 2015 at 8:11 PM, Thomas Auge <lists at 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 at 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 at 10.110.36.194:5060>;tag=QS5Na83Q2g2gj
   To: <sip:9196 at 10.110.36.194:5060>;tag=8U51K76U4yB1N
   Call-ID: 783bfcc8-e874-1233-e0b3-989096a9db3a
   CSeq: 913303564 INVITE
   Contact: <sip:9196 at 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 at 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 at qnective.com>johannes.singler at 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 at qnective.com>
> johannes.singler at qnective.com
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>
> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20151008/6003a6a8/attachment-0001.html 