[Freeswitch-users] SRTP issue with latest master + (possible) DTMF change

[Privus 007]

Ok, so I applied the changes in the dialplan and still there's a crypto
problem.
I actually decided to put aside my previous diaplan and am testing with the
default one provided by master.

Now indeed I see that crypto gets properly detected in the default
dialplan, and it gets exported to b leg:

Dialplan: sofia/external/1010 at mydomain Regex (PASS) [global]
${rtp_has_crypto}(AES_CM_128_HMAC_SHA1_80) =~
/^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$/ break=never
Dialplan: sofia/external/1010 at mydomain Action set(rtp_secure_media=true)
Dialplan: sofia/external/1010 at mydomain Action export(rtp_secure_media=true)


But then I see it still doesn't pass the rtp_secure_media_confirmed check.

Dialplan: sofia/external/1010 at mydomain parsing [features->is_secure]
continue=true
Dialplan: sofia/external/1010 at mydomain Regex (PASS) [is_secure]
${sip_via_protocol}(tls) =~ /tls/ break=on-false
Dialplan: sofia/external/1010 at mydomain Regex (FAIL) [is_secure]
${rtp_secure_media_confirmed}() =~ /^true$/ break=on-false
Dialplan: sofia/external/1010 at mydomain ANTI-Action eval(not_secure)
2013-11-15 13:33:38.386273 [NOTICE] switch_core_session.c:2940 Execute
eval(not_secure)
EXECUTE sofia/external/1010 at mydomain eval(not_secure)


So what am I doing wrong? Why is it failing
rtp_secure_media_confirmed? Should I change it to plain
rtp_secure_media and leave out the "confirmed" bit, or do I have to
change var names somewhere else besides the default and features
dialplan?


Thanks



On Fri, Nov 15, 2013 at 1:36 AM, Privus 007 <privus007 at gmail.com> wrote:

> Ah, I see. Thank you both
>
>
> On Fri, Nov 15, 2013 at 1:02 AM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
>> The var names are rtp_ for those instead of sip_ now.
>> On Nov 14, 2013 4:46 PM, "Privus 007" <privus007 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I've been using FS successfully for some years now. Recently I decided
>>> to update from 1.2.12 to latest master via git (running FS on bare metal
>>> Debian 7.0 64bit)
>>>
>>> Obviously I saved my conf directory and tried to apply it to the
>>> 1.5.7b+git~20131114 version I just installed and have up and running.
>>>
>>> I realize that master is not yet stable but I notice that there seems to
>>> be some incompatibility issues, namely with SRTP.
>>>
>>> All my SRTP calls are now failing with "incompatible destination"
>>> messages in the logs, and looking through them more closely I see this:
>>>
>>>
>>> parsing [features->is_secure] continue=true
>>> Dialplan: sofia/external/1000 at mydomain Regex (PASS) [is_secure]
>>> ${sip_via_protocol}(tls) =~ /tls/ break=on-false
>>> Dialplan: sofia/external/1000 at mydomain Regex (FAIL) [is_secure]
>>> ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false
>>> Dialplan: sofia/external/1000 at mydomain ANTI-Action eval(not_secure)
>>> 2013-11-14 22:02:22.006273 [NOTICE] switch_core_session.c:2940 Execute
>>> eval(not_secure)
>>>
>>>
>>> Notice the FAIL for sip_secure_media_confirmed. This is very strange
>>> since I'm sure that SRTP is enabled (both CSipSimple Android client and
>>> Groundwire iOS client confirm that indeed the signalling is secured via TLS
>>> and the media via SDES SRTP).
>>> A few seconds earlier in the logs, FS also sees the crypto taking place
>>> and there doesn't seem to be any problem
>>>
>>> 2013-11-14 22:02:21.986279 [INFO] switch_rtp.c:2830 Activating Audio
>>> Secure RTP SEND
>>> 2013-11-14 22:02:21.986279 [DEBUG] switch_core_sqldb.c:2354 Secure Type:
>>> srtp:sdes:AES_CM_128_HMAC_SHA1_80
>>>
>>> So the problem seems to be with the sip_secure_media_confirmed variable.
>>> This same setup worked fine yesterday with 1.2.12, so I'm at a loss as to
>>> what changed.
>>> Any ideas? To further add some confusion, since my clients are
>>> configured for mandatory SRTP, all calls to them fail, and FS routes to VM.
>>> So far, pretty normal. Except that the VM message we usually hear sounds
>>> super slow like the voice is drunk. This is definetely not normal, but I'm
>>> not sure if it's related to the crypto issue. I don't think it's a flite
>>> issue since calling into the IVR sounds as normal as ever.
>>>
>>> Also, I notice a change in FS handling DTMF. My CSipSimple client which
>>> worked flawlessly with DTMF before now just doesn't work at all, but my
>>> Groundwire client continues to send DTMF without a problem.
>>> Has something changed in the latest master regarding DTMF?
>>>
>>> I'd appreciate any help in debugging these issues. Perhaps the new conf
>>> in latest master has different variables or options and by simply copying
>>> my old conf directory over the new one wasn't too smart after all.
>>>
>>> Thanks
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.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
>>>
>>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20131115/f01342dc/attachment.html