SRTP issue with latest master + (possible) DTMF change
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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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
Change your conditions to rtp_secure_media instead of sip_secure_media. On Thursday, November 14, 2013, Privus 007 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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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
-- Sent from mobile device
The var names are rtp_ for those instead of sip_ now. On Nov 14, 2013 4:46 PM, "Privus 007" <privus007@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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Ah, I see. Thank you both On Fri, Nov 15, 2013 at 1:02 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The var names are rtp_ for those instead of sip_ now. On Nov 14, 2013 4:46 PM, "Privus 007" <privus007@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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
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@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@mydomain Action set(rtp_secure_media=true) Dialplan: sofia/external/1010@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@mydomain parsing [features->is_secure] continue=true Dialplan: sofia/external/1010@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1010@mydomain Regex (FAIL) [is_secure] ${rtp_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1010@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@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@gmail.com> wrote:
Ah, I see. Thank you both
On Fri, Nov 15, 2013 at 1:02 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The var names are rtp_ for those instead of sip_ now. On Nov 14, 2013 4:46 PM, "Privus 007" <privus007@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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
that var is now split into rtp_secure_audio_confirmed rtp_secure_video_confirmed so in your case, change media to audio. On Fri, Nov 15, 2013 at 7:44 AM, Privus 007 <privus007@gmail.com> wrote:
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@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@mydomain Action set(rtp_secure_media=true) Dialplan: sofia/external/1010@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@mydomain parsing [features->is_secure] continue=true
Dialplan: sofia/external/1010@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1010@mydomain Regex (FAIL) [is_secure] ${rtp_secure_media_confirmed}() =~ /^true$/ break=on-false
Dialplan: sofia/external/1010@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@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@gmail.com> wrote:
Ah, I see. Thank you both
On Fri, Nov 15, 2013 at 1:02 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The var names are rtp_ for those instead of sip_ now. On Nov 14, 2013 4:46 PM, "Privus 007" <privus007@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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Ah, that did the trick. Finally got it working again. Are those changes documented anywhere? Also, I see that FS has better ICE handling, but I can't find any documentation on that either. Thanks On Fri, Nov 15, 2013 at 4:08 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
that var is now split into
rtp_secure_audio_confirmed rtp_secure_video_confirmed
so in your case, change media to audio.
On Fri, Nov 15, 2013 at 7:44 AM, Privus 007 <privus007@gmail.com> wrote:
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@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@mydomain Action set(rtp_secure_media=true) Dialplan: sofia/external/1010@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@mydomain parsing [features->is_secure] continue=true
Dialplan: sofia/external/1010@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1010@mydomain Regex (FAIL) [is_secure] ${rtp_secure_media_confirmed}() =~ /^true$/ break=on-false
Dialplan: sofia/external/1010@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@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@gmail.com> wrote:
Ah, I see. Thank you both
On Fri, Nov 15, 2013 at 1:02 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The var names are rtp_ for those instead of sip_ now. On Nov 14, 2013 4:46 PM, "Privus 007" <privus007@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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
It will probably be documented when 1.4 is full beta. On Fri, Nov 15, 2013 at 11:35 AM, Privus 007 <privus007@gmail.com> wrote:
Ah, that did the trick. Finally got it working again.
Are those changes documented anywhere? Also, I see that FS has better ICE handling, but I can't find any documentation on that either.
Thanks
On Fri, Nov 15, 2013 at 4:08 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
that var is now split into
rtp_secure_audio_confirmed rtp_secure_video_confirmed
so in your case, change media to audio.
On Fri, Nov 15, 2013 at 7:44 AM, Privus 007 <privus007@gmail.com> wrote:
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@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@mydomain Action set(rtp_secure_media=true) Dialplan: sofia/external/1010@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@mydomain parsing [features->is_secure] continue=true
Dialplan: sofia/external/1010@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1010@mydomain Regex (FAIL) [is_secure] ${rtp_secure_media_confirmed}() =~ /^true$/ break=on-false
Dialplan: sofia/external/1010@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@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@gmail.com> wrote:
Ah, I see. Thank you both
On Fri, Nov 15, 2013 at 1:02 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The var names are rtp_ for those instead of sip_ now. On Nov 14, 2013 4:46 PM, "Privus 007" <privus007@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@mydomain Regex (PASS) [is_secure] ${sip_via_protocol}(tls) =~ /tls/ break=on-false Dialplan: sofia/external/1000@mydomain Regex (FAIL) [is_secure] ${sip_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: sofia/external/1000@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (3)
-
Anthony Minessale
-
Kristian Kielhofner
-
Privus 007