Re: [Freeswitch-users] Secure RTP
Jim Burke j...@evolutiontel.net wrote: extension name=On-Net_calls condition field=destination_number expression=^103$ action application=set data=continue_on_fail=79/ action application=set data=continue_on_fail=true/ Why are you setting the same variable twice? The result will be that only the second of the above set commands takes effect, so you should delete the first of them. ___ 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
Re: [Freeswitch-users] Secure RTP
Jim Burke j...@evolutiontel.net wrote: If I understand your comment correctly, I did not have both of the above snippets in the dialplan at the same time. The dialplan was modified continually to get the correct vars that worked for my situation and then reloadxml to get them working. Right, you can't have action application=set data=continue_on_fail=79/ action application=set data=continue_on_fail=true/ one after the other like this, because it is equivalent to action application=set data=continue_on_fail=true/ since you're overriding the setting of the variable in the very next line. ___ 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
Re: [Freeswitch-users] Secure RTP
Ahh right now I get what you are saying, I thought from the wiki that I would have to set the feature on and then tell it what cause codes I wanted to trap. Will fix up my dialplan cause I don't want it to trap other causes for this scenario. Thanks! On Tue, May 26, 2009 at 6:09 PM, Jason White ja...@jasonjgw.net wrote: Jim Burke j...@evolutiontel.net wrote: If I understand your comment correctly, I did not have both of the above snippets in the dialplan at the same time. The dialplan was modified continually to get the correct vars that worked for my situation and then reloadxml to get them working. Right, you can't have action application=set data=continue_on_fail=79/ action application=set data=continue_on_fail=true/ one after the other like this, because it is equivalent to action application=set data=continue_on_fail=true/ since you're overriding the setting of the variable in the very next line. ___ 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 ___ 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
Re: [Freeswitch-users] Secure RTP
I know this but you don't have to have it in x-lite or eyebeam directly. You just need the zfone application along with Eyebeam or X- Lite right now. /b On May 26, 2009, at 12:52 AM, Jim Burke wrote: FYI...According to Counterpath ZRTP is not added to the retail versions of Eyebeam or X-Lite, you need to purchase a bulk order. ___ 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
Re: [Freeswitch-users] Secure RTP
Hi Gents, After much testing today, I have found the answer to this question. The following dialplan works as expected and the B leg is encryted while the A leg is not. extension name=On-Net_calls condition field=destination_number expression=^103$ action application=set data=continue_on_fail=79/ action application=set data=continue_on_fail=true/ action application=set data=bypass_media=false/ action application=bridge data=sofia/sip.evolutiontel.net/0631000...@192.168.0.3 / action application=export data=sip_secure_media=true/ action application=bridge data=sofia/sip.evolutiontel.net/0631000...@192.168.0.3 / /condition /extension As I wanted to bypass_media unless SRTP was enforced by either party I found that FS would not set bypass_media to false unless pre_answer was added. extension name=On-Net_calls condition field=destination_number expression=^103$ action application=set data=continue_on_fail=79/ action application=set data=continue_on_fail=true/ action application=set data=bypass_media=true/ action application=bridge data=sofia/sip.evolutiontel.net/0631000...@192.168.0.3 / action application=set data=bypass_media=false/ action application=export data=sip_secure_media=true/ action application=pre_answer/ action application=bridge data=sofia/sip.evolutiontel.net/0631000...@192.168.0.3 / /condition /extension FYI...According to Counterpath ZRTP is not added to the retail versions of Eyebeam or X-Lite, you need to purchase a bulk order. Regards, Jim On Mon, May 25, 2009 at 1:23 PM, Jim Burke j...@evolutiontel.net wrote: Hi Brian and Anthony, We need to move back a couple of steps here. I fully understand the A leg cannot enable SRTP unless it sends descriptors in the original INVITE. As the A party works as expected lets not discuss that any further as it clouds the waters so to speak. What I am trying to achieve is to set SRTP on a per leg basis if the UA requires it. In the case of terminating the B leg, if the UA requires SRTP, Freeswitch will not know this until advised by the B leg UA via a 415 Bad Security Level responce from the B leg INVITE. Per debug attached to original email, FS appears to generate the SRTP descriptors however does not add them to the second INVITE sent to the B leg. IMHO this is a fault and should be corrected. Anthony, do you have any thoughts on this! Call testing shows the following results. 1. A leg INVITE with SRTP descriptors in SDP and sip_secure_media set in the dialplan. B leg INVITE has no SRTP descriptors in SDP . RTP between A UA and FS uses SRTP, B leg does not. 2. A leg INVITE with SRTP descriptors in SDP and sip_secure_media and export sip_secure_media=true set in the dialplan. B leg INVITE also SRTP descriptors in SDP . RTP between A UA and FS uses SRTP, FS and B UA also uses SRTP. 3. A leg INVITE with no SRTP descriptors in SDP and export sip_secure_media=true set in the dialplan. B leg INVITE has SRTP descriptors in SDP. RTP between B UA and FS uses SRTP, A leg does not. 4. A leg INVITE without SRTP descriptors in SDP, B leg INVITE without SRTP descriptors in SDP results in 415 Bad Security Level. Dialplan set to continue on fail and export sip_secure_media=true then bridge the call once more. Debug shows that FS generates the SRTP descriptors, however FS does not add them to the second INVITE. As you can see from above, FS can set SRTP on a per leg basis. However for some reason it fails to add the SRTP descriptors to the SDP in the second INVITE for scenario 3. I hope this has cleared up the confusion regarding my original email. If you wish to discuss further please let me know what time the conference is and I can join in. Regards, Jim On Fri, May 22, 2009 at 11:59 PM, Brian West br...@freeswitch.org wrote: On May 22, 2009, at 12:47 AM, Jim Burke wrote: Hey Brian, Will have a look at ZRTP :) Not sure I understand your comments regarding its all over once receiving the 415 from the B party. Is'nt that what parm continue_on_fail does? The fact that it sends the invite back out sorta proves this. The A-LEG has to hangup to re-enable SRTP it can't do it if it didn't invite with it in the first place. The other point of interest here is that if you set action application=export data=sip_secure_media=true/ before the first bridge function it will include the security descriptions in the B leg INVITE even when the A leg does not have them and the call will succeed. The B Eyebeam will show the locked padlock while A does not. Make sure you do not answer the call before you do it. From what I can see in code it is this guy that must stop it all from happening. TFLAG_SECURE But I dont understand why :( Again you have to invite to FS with crypto it can't magically cause crypto to work unless you initiate
Re: [Freeswitch-users] Secure RTP
Hi Brian and Anthony, We need to move back a couple of steps here. I fully understand the A leg cannot enable SRTP unless it sends descriptors in the original INVITE. As the A party works as expected lets not discuss that any further as it clouds the waters so to speak. What I am trying to achieve is to set SRTP on a per leg basis if the UA requires it. In the case of terminating the B leg, if the UA requires SRTP, Freeswitch will not know this until advised by the B leg UA via a 415 Bad Security Level responce from the B leg INVITE. Per debug attached to original email, FS appears to generate the SRTP descriptors however does not add them to the second INVITE sent to the B leg. IMHO this is a fault and should be corrected. Anthony, do you have any thoughts on this! Call testing shows the following results. 1. A leg INVITE with SRTP descriptors in SDP and sip_secure_media set in the dialplan. B leg INVITE has no SRTP descriptors in SDP . RTP between A UA and FS uses SRTP, B leg does not. 2. A leg INVITE with SRTP descriptors in SDP and sip_secure_media and export sip_secure_media=true set in the dialplan. B leg INVITE also SRTP descriptors in SDP . RTP between A UA and FS uses SRTP, FS and B UA also uses SRTP. 3. A leg INVITE with no SRTP descriptors in SDP and export sip_secure_media=true set in the dialplan. B leg INVITE has SRTP descriptors in SDP. RTP between B UA and FS uses SRTP, A leg does not. 4. A leg INVITE without SRTP descriptors in SDP, B leg INVITE without SRTP descriptors in SDP results in 415 Bad Security Level. Dialplan set to continue on fail and export sip_secure_media=true then bridge the call once more. Debug shows that FS generates the SRTP descriptors, however FS does not add them to the second INVITE. As you can see from above, FS can set SRTP on a per leg basis. However for some reason it fails to add the SRTP descriptors to the SDP in the second INVITE for scenario 3. I hope this has cleared up the confusion regarding my original email. If you wish to discuss further please let me know what time the conference is and I can join in. Regards, Jim On Fri, May 22, 2009 at 11:59 PM, Brian West br...@freeswitch.org wrote: On May 22, 2009, at 12:47 AM, Jim Burke wrote: Hey Brian, Will have a look at ZRTP :) Not sure I understand your comments regarding its all over once receiving the 415 from the B party. Is'nt that what parm continue_on_fail does? The fact that it sends the invite back out sorta proves this. The A-LEG has to hangup to re-enable SRTP it can't do it if it didn't invite with it in the first place. The other point of interest here is that if you set action application=export data=sip_secure_media=true/ before the first bridge function it will include the security descriptions in the B leg INVITE even when the A leg does not have them and the call will succeed. The B Eyebeam will show the locked padlock while A does not. Make sure you do not answer the call before you do it. From what I can see in code it is this guy that must stop it all from happening. TFLAG_SECURE But I dont understand why :( Again you have to invite to FS with crypto it can't magically cause crypto to work unless you initiate it with your first invite. Regards, Jim Brian West br...@freeswitch.org -- Meet us at ClueCon! 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 ___ 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
Re: [Freeswitch-users] Secure RTP
On May 22, 2009, at 12:47 AM, Jim Burke wrote: Hey Brian, Will have a look at ZRTP :) Not sure I understand your comments regarding its all over once receiving the 415 from the B party. Is'nt that what parm continue_on_fail does? The fact that it sends the invite back out sorta proves this. The A-LEG has to hangup to re-enable SRTP it can't do it if it didn't invite with it in the first place. The other point of interest here is that if you set action application=export data=sip_secure_media=true/ before the first bridge function it will include the security descriptions in the B leg INVITE even when the A leg does not have them and the call will succeed. The B Eyebeam will show the locked padlock while A does not. Make sure you do not answer the call before you do it. From what I can see in code it is this guy that must stop it all from happening. TFLAG_SECURE But I dont understand why :( Again you have to invite to FS with crypto it can't magically cause crypto to work unless you initiate it with your first invite. Regards, Jim Brian West br...@freeswitch.org -- Meet us at ClueCon! 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
[Freeswitch-users] Secure RTP
Hi All,
Have been trying to workout how to solve a call scenario involving
SRTP and need some help.
The scenario is:
Eyebeam FS-Eyebeam with make and accept only encrypted calls set.
What I am hoping to acheive is, if the A leg does not have SRTP set
and no SRTP Descriptors are sent in the INVITE to the B leg, when the
B leg responds with 415 Bad Security Level this is intercepted and a
re-invite is sent with the security descriptions so this call, 1,
terminates and 2, is B leg secure.
In my dialplan I have CONTINUE_ON_FAILURE set for 79 and then set
BYPASS_MEDIA=FALSE (was SET true earlier in the Dialplan) and EXPORT
SIP_SECURE_MEDIA=TRUE then finaly bridge the call once more.
What I get is
Eyebeam FS Eyebeam
INVITE no SRTP
---100 Trying -
INVITE no SRTP
---415 Bad Security
INVITE no SRTP
Based on the following debug snippet showing the continue on fail
occuring, the Local Key is generated, however it is not added to the
second INVITE message when sent out.
2009-05-22 13:23:40 [DEBUG] switch_ivr_originate.c:2094
switch_ivr_originate() Originate Resulted in Error Cause: 79
[SERVICE_NOT_IMPLEMENTED]
2009-05-22 13:23:40 [INFO] mod_dptools.c:2074 audio_bridge_function()
Originate Failed. Cause: SERVICE_NOT_IMPLEMENTED
2009-05-22 13:23:40 [DEBUG] mod_dptools.c:2101 audio_bridge_function()
Continue on fail [true]: Cause: SERVICE_NOT_IMPLEMENTED
EXECUTE sofia/internal/0631000...@sip.evolutiontel.net set(bypass_media=false)
2009-05-22 13:23:40 [DEBUG] mod_dptools.c:748 set_function()
sofia/internal/0631000...@sip.evolutiontel.net SET
[bypass_media]=[false]
EXECUTE sofia/internal/0631000...@sip.evolutiontel.net
export(sip_secure_media=true)
2009-05-22 13:23:40 [DEBUG] mod_dptools.c:886 export_function() EXPORT
[sip_secure_media]=[true]
EXECUTE sofia/internal/0631000...@sip.evolutiontel.net
export(sip_crypto_mandatory=true)
2009-05-22 13:23:40 [DEBUG] mod_dptools.c:886 export_function() EXPORT
[sip_crypto_mandatory]=[true]
EXECUTE sofia/internal/0631000...@sip.evolutiontel.net
bridge({sip_from_uri=sip:0631000...@sip.evolutiontel.net}sofia/sip.evolutiontel.net/0631000...@192.168.0.3^103@sip.evolutiontel.net)
2009-05-22 13:23:40 [DEBUG] switch_ivr_originate.c:1082
switch_ivr_originate() variable string 0 =
[sip_from_uri=sip:0631000...@sip.evolutiontel.net]
2009-05-22 13:23:40 [NOTICE] switch_channel.c:602
switch_channel_set_name() New Channel
sofia/internal/0631000...@192.168.0.3
[b0e7a29c-b154-4b9c-b851-4d987669571f]
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:2659 sofia_outgoing_channel()
(sofia/internal/0631000...@192.168.0.3) State Change CS_NEW - CS_INIT
2009-05-22 13:23:40 [DEBUG] switch_core_session.c:933
switch_core_session_signal_state_change() Send signal
sofia/internal/0631000...@192.168.0.3 [BREAK]
2009-05-22 13:23:40 [NOTICE] switch_core_session.c:1085
switch_core_session_thread() Session 225
(sofia/internal/0631000...@192.168.0.3) Ended
2009-05-22 13:23:40 [NOTICE] switch_core_session.c:1087
switch_core_session_thread() Close Channel
sofia/internal/0631000...@192.168.0.3 [CS_DESTROY]
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:559
switch_core_session_destroy_state()
(sofia/internal/0631000...@192.168.0.3) State DESTROY
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:240 sofia_on_destroy()
sofia/internal/0631000...@192.168.0.3 SOFIA DESTROY
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:60
switch_core_standard_on_destroy()
sofia/internal/0631000...@192.168.0.3 Standard DESTROY
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:559
switch_core_session_destroy_state()
(sofia/internal/0631000...@192.168.0.3) State DESTROY going to sleep
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:397
switch_core_session_run() (sofia/internal/0631000...@192.168.0.3)
Running State Change CS_INIT
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:480
switch_core_session_run() (sofia/internal/0631000...@192.168.0.3)
State INIT
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:83 sofia_on_init()
sofia/internal/0631000...@192.168.0.3 SOFIA INIT
2009-05-22 13:23:40 [DEBUG] sofia_glue.c:1972
sofia_glue_build_crypto() Set Local Key [1 AES_CM_128_HMAC_SHA1_32
inline:0mENEM7ab0d6DtmcCMgDmbHXlYIHpdXdLnVCtFYX]
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:111 sofia_on_init()
(sofia/internal/0631000...@192.168.0.3) State Change CS_INIT -
CS_ROUTING
2009-05-22 13:23:40 [DEBUG] switch_core_session.c:933
switch_core_session_signal_state_change() Send signal
sofia/internal/0631000...@192.168.0.3 [BREAK]
2009-05-22 13:23:40 [DEBUG] sofia.c:2911 sofia_handle_sip_i_state()
Channel sofia/internal/0631000...@192.168.0.3 entering state
[calling][0]
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:480
switch_core_session_run()
Re: [Freeswitch-users] Secure RTP
Jim,
You seem to be making the whole ordeal overly complex for no reason.
condition field=${sip_has_crypto}
expression=^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$
break=never
!-- export sets it local and on export --
action application=export data=sip_secure_media=$
{sip_has_crypto}/
anti-action application=respond data=503 TURN ON SRTP/
/condition
You can not accept the call and send it out and get a 415 back and
expect to do the process all over again automatically. Once you get
the 415 its done.. finished OVER gotta do it again. Remember we are a
B2BUA not a proxy... so its all done per leg.
If all else fails just go get libzrtp and install it as per the wiki
and enable zrtp support. Then get zfone for your two PC's and you're
done. We don't do the trusted man in the middle stuff yet but you can
get the same end result.
/b
On May 21, 2009, at 11:17 PM, Jim Burke wrote:
What I am hoping to acheive is, if the A leg does not have SRTP set
and no SRTP Descriptors are sent in the INVITE to the B leg, when the
B leg responds with 415 Bad Security Level this is intercepted and a
re-invite is sent with the security descriptions so this call, 1,
terminates and 2, is B leg secure.
Brian West
br...@freeswitch.org
-- Meet us at ClueCon! 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
Re: [Freeswitch-users] Secure RTP
Hey Brian,
Will have a look at ZRTP :)
Not sure I understand your comments regarding its all over once
receiving the 415 from the B party. Is'nt that what parm
continue_on_fail does? The fact that it sends the invite back out
sorta proves this.
The other point of interest here is that if you set action
application=export data=sip_secure_media=true/ before the first
bridge function it will include the security descriptions in the B leg
INVITE even when the A leg does not have them and the call will
succeed. The B Eyebeam will show the locked padlock while A does not.
From what I can see in code it is this guy that must stop it all from
happening. TFLAG_SECURE But I dont understand why :(
Regards,
Jim
On Fri, May 22, 2009 at 2:44 PM, Brian West br...@freeswitch.org wrote:
Jim,
You seem to be making the whole ordeal overly complex for no reason.
condition field=${sip_has_crypto}
expression=^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$
break=never
!-- export sets it local and on export --
action application=export
data=sip_secure_media=${sip_has_crypto}/
anti-action application=respond data=503 TURN ON SRTP/
/condition
You can not accept the call and send it out and get a 415 back and expect to
do the process all over again automatically. Once you get the 415 its
done.. finished OVER gotta do it again. Remember we are a B2BUA not a
proxy... so its all done per leg.
If all else fails just go get libzrtp and install it as per the wiki and
enable zrtp support. Then get zfone for your two PC's and you're done. We
don't do the trusted man in the middle stuff yet but you can get the same
end result.
/b
On May 21, 2009, at 11:17 PM, Jim Burke wrote:
What I am hoping to acheive is, if the A leg does not have SRTP set
and no SRTP Descriptors are sent in the INVITE to the B leg, when the
B leg responds with 415 Bad Security Level this is intercepted and a
re-invite is sent with the security descriptions so this call, 1,
terminates and 2, is B leg secure.
Brian West
br...@freeswitch.org
-- Meet us at ClueCon! 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
___
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
