[Freeswitch-users] SRTP disabling

[Michael Jerris]

Why not just ask yealink to fix this?  They have been pretty good about making fixes for us.

Mike

On Feb 14, 2013, at 10:03 AM, Levend Sayar <levend.sayar at karel.com.tr> wrote:

> Thanks for your kind responses Steve.
> 
> Phones are same brand, you are right. And not Polycom or Linksys. They are Yealink phones.
> 
> I found the code piece handling the RTP/SAVP part you mentioned. (sofia_glue_negotiate_sdp function). 
> Although it is not wise, I will add a new channel variable and try to disable SRTP even if phone says SRTP is mandatory. 
> I need that.
> 
> 
> On Wed, 2013-02-13 at 17:59 +0000, Steven Ayre wrote:
>> If the phone is Polycom or Linksys have you read the notes on http://wiki.freeswitch.org/wiki/SRTP?
>> 
>> On 13 February 2013 17:53, Steven Ayre <steveayre at gmail.com> wrote:
>> Nevertheless it's not being negotiated and this is possibly a bug in the phone. Adding a workaround in FS would decrease security because the phone is explicitly saying it'll only accept SRTP so sending plain RTP wouldn't be wise.
>> 
>> I assume both phones are the same make?
>> 
>> On 7 February 2013 13:54, Levend Sayar <levend.sayar at karel.com.tr> wrote:
>> But the very same phone calls another phone and talk with RTP, not SRTP if the peer does not accept SRTP
>> 
>> Here is the SDP offer by the same phone
>> 
>> v=0
>> o=- 20186 20186 IN IP4 192.168.173.69
>> 
>> s=SDP data
>> c=IN IP4 192.168.173.69
>> t=0 0
>> 
>> m=audio 11782 RTP/SAVP 0 8 18 9 101
>> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:NzFmYjdiMjk1OTY2ODQwYzExZjM0ZmE2NGM0YWMw
>> a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:M2MxMTE2OWFjOGY2ZjEwADEzZmZkNzAxNjRlMzFm
>> a=crypto:3 F8_128_HMAC_SHA1_80 inline:NjkzZDg2Mjk0ZTkxMjg1YzdmYjFiNjRlMmFhNGFm
>> 
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:9 G722/8000
>> a=fmtp:101 0-15
>> a=rtpmap:101 telephone-event/8000
>> a=ptime:20
>> a=sendrecv
>> 
>> 
>> And here is the SDP answer sent by the other phone
>> 
>> v=0
>> o=- 20029 20029 IN IP4 192.168.173.65
>> s=SDP data
>> c=IN IP4 192.168.173.65
>> t=0 0
>> m=audio 11794 RTP/SAVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=sendrecv
>> a=ptime:20
>> 
>> a=fmtp:101 0-15
>> a=rtpmap:101 telephone-event/8000
>> 
>> 
>> On Thu, 2013-02-07 at 13:37 +0000, Steven Ayre wrote:
>>> m=audio 11780 RTP/SAVP 0 8 18 9 101 
>>> 
>>> 
>>> RTP/SAVP means SRTP is mandatory. You need to reconfigure the phone.
>>> 
>>> 
>>> If the phone sends RTP/AVP then that means plain RTP, and RTP/AVP with a a=crypto attribute means SRTP is optional.
>>> 
>>> On 7 February 2013 13:26, Levend Sayar <levend.sayar at karel.com.tr> wrote:
>>> Below is the SDP  offer sent by the phone.
>>> 
>>> v=0
>>> o=- 20185 20185 IN IP4 192.168.173.69
>>> s=SDP data
>>> c=IN IP4 192.168.173.69
>>> t=0 0
>>> m=audio 11780 RTP/SAVP 0 8 18 9 101
>>> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:MTM2MjVhMGI1NDZjYmRjADU5NWVjNGVkNTNlYzA1
>>> a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:YmExYmZhNQAzN2ZjNDgzYTRkNGU2ZjFiN2Q0MmE3
>>> a=crypto:3 F8_128_HMAC_SHA1_80 inline:N2Q2NTRiYQAxZjA3MWY3ZjI1YTI5NjIyM2FjODYw
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:18 G729/8000
>>> a=fmtp:18 annexb=no
>>> a=rtpmap:9 G722/8000
>>> a=fmtp:101 0-15
>>> a=rtpmap:101 telephone-event/8000
>>> a=ptime:20
>>> a=sendrecv
>>> 
>>> 
>>> 
>>> And below is the SDP answer sent by FS
>>> 
>>> v=0
>>> o=FreeSWITCH 1360230601 1360230602 IN IP4 192.168.169.114
>>> s=FreeSWITCH
>>> c=IN IP4 192.168.169.114
>>> t=0 0
>>> m=audio 12532 RTP/SAVP 9 101
>>> a=rtpmap:9 G722/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=silenceSupp:off - - - -
>>> a=ptime:20
>>> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:l8v0R64H7CP0vEx9j0Ycdbob8bgMCpLDppWGy7Dy
>>> 
>>> On Thu, 2013-02-07 at 13:09 +0000, Steven Ayre wrote:
>>>> What I mean is you'll see two separate m=audio lines within the callee's SDP, one for 'RTP/AVP' and one for 'SRTP/AVP'. If there is no m=audio line for RTP/AVP the caller won't know of a port that's expecting RTP. So if the callee only sends SRTP/AVP the caller can't send RTP. 
>>>> 
>>>> 
>>>> Can you show us the SDP being sent by the phone? 
>>>> 
>>>> 
>>>> 
>>>> On 7 February 2013 11:01, Levend Sayar <levend.sayar at karel.com.tr> wrote:
>>>> Thanx Steven. 
>>>> 
>>>> 
>>>> Caller makes the offer for SDP but callee chooses whatever it wants. So caller can offer SRTP but callee can prefer not to talk encrypted. In our case I want FS to choose non secure media.
>>>> Phone will offer SRTP on the conference call but FS must prefer RTP, not SRTP.
>>>> 
>>>> On 7 Şub 2013, at 11:13, "Steven Ayre" <steveayre at gmail.com> wrote:
>>>> 
>>>> 
>>>>> It's also going to rely on the phone actually offering RTP/AVP as well as SRTP/AVP in their SDP - without that there'd be nowhere to send insecure RTP.
>>>>> 
>>>>> 
>>>>> On 6 February 2013 16:09, Levend Sayar <levend.sayar at karel.com.tr> wrote:
>>>>> Thanks Daniel for the reply. 
>>>>> 
>>>>> 
>>>>> I tried 
>>>>> 
>>>>> 
>>>>> <action application="set" data="sip_secure_media=false" /> 
>>>>> 
>>>>> 
>>>>> But did not work. Upon your reply I also tried 
>>>>> 
>>>>> 
>>>>> <action application="set" data="secure_media=false" /> 
>>>>> 
>>>>> 
>>>>> But did not work either. I am doing something wrong ?
>>>>> 
>>>>> On 6 Şub 2013, at 18:00, "Daniel Ivanov" <sertys at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> Of course you can. Just set the secure_media var to false and you will be srtp-free in sip.
>>>>>> 
>>>>>> On Feb 5, 2013 6:06 PM, "Levend Sayar" <levend.sayar at karel.com.tr> wrote:
>>>>>> Hi all.
>>>>>> 
>>>>>> I am using FS as a conference server. Some of my phones are using SRTP , some of them not. Both type of phone can
>>>>>> join a conference. FS can talk to each peer with SRTP or not depending on the phone itself.
>>>>>> 
>>>>>> My question:
>>>>>> 
>>>>>> Is it possible to disable SRTP on FS ?
>>>>>> 
>>>>>> I suppose if i can disable SRTP, FS will talk without SRTP with each phone whether they are using SRTP or not.
>>>>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130214/78aaf910/attachment-0001.html