VoIP Mailing List Archives

[jim at evolutiontel.net]

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/0631000002@sip.evolutiontel.net set(bypass_media=false)
2009-05-22 13:23:40 [DEBUG] mod_dptools.c:748 set_function()
sofia/internal/0631000002@sip.evolutiontel.net SET
[bypass_media]=[false]
EXECUTE sofia/internal/0631000002@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/0631000002@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/0631000002@sip.evolutiontel.net
bridge({sip_from_uri=sip:0631000002@sip.evolutiontel.net}sofia/sip.evolutiontel.net/0631000006@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:0631000002@sip.evolutiontel.net]
2009-05-22 13:23:40 [NOTICE] switch_channel.c:602
switch_channel_set_name() New Channel
sofia/internal/0631000006@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/0631000006@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/0631000006@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/0631000006@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/0631000006@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/0631000006@192.168.0.3) State DESTROY
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:240 sofia_on_destroy()
sofia/internal/0631000006@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/0631000006@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/0631000006@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/0631000006@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/0631000006@192.168.0.3)
State INIT
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:83 sofia_on_init()
sofia/internal/0631000006@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/0631000006@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/0631000006@192.168.0.3 [BREAK]
2009-05-22 13:23:40 [DEBUG] sofia.c:2911 sofia_handle_sip_i_state()
Channel sofia/internal/0631000006@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() (sofia/internal/0631000006@192.168.0.3)
State INIT going to sleep
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:397
switch_core_session_run() (sofia/internal/0631000006@192.168.0.3)
Running State Change CS_ROUTING
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:483
switch_core_session_run() (sofia/internal/0631000006@192.168.0.3)
State ROUTING
2009-05-22 13:23:40 [DEBUG] mod_sofia.c:130 sofia_on_routing()
sofia/internal/0631000006@192.168.0.3 SOFIA ROUTING
2009-05-22 13:23:40 [DEBUG] switch_ivr_originate.c:63
originate_on_routing() (sofia/internal/0631000006@192.168.0.3) State
Change CS_ROUTING -> CS_CONSUME_MEDIA
2009-05-22 13:23:40 [DEBUG] switch_core_session.c:933
switch_core_session_signal_state_change() Send signal
sofia/internal/0631000006@192.168.0.3 [BREAK]
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:483
switch_core_session_run() (sofia/internal/0631000006@192.168.0.3)
State ROUTING going to sleep
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:397
switch_core_session_run() (sofia/internal/0631000006@192.168.0.3)
Running State Change CS_CONSUME_MEDIA
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:502
switch_core_session_run() (sofia/internal/0631000006@192.168.0.3)
State CONSUME_MEDIA
2009-05-22 13:23:40 [DEBUG] switch_core_state_machine.c:502
switch_core_session_run() (sofia/internal/0631000006@192.168.0.3)
State CONSUME_MEDIA going to sleep
2009-05-22 13:23:40 [DEBUG] sofia.c:2911 sofia_handle_sip_i_state()
Channel sofia/internal/0631000006@192.168.0.3 entering state
[terminated][415]


If I swap and A leg is set to have SRTP and B party does not it will
be setup with only the A leg having SRTP and the B leg being normal
RTP.

Let me know if you need any further info, or if this is a fault and
will need a jira ticket opened.

FreeSWITCH Version 1.0.trunk (13232)

Thanks,
Jim

_______________________________________________
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

[brian at freeswitch.org]

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:

[jim at evolutiontel.net]

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.

[brian at freeswitch.org]

On May 22, 2009, at 12:47 AM, Jim Burke wrote:

[jim at evolutiontel.net]

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 <brian@freeswitch.org> wrote:

[jim at evolutiontel.net]

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/0631000006@192.168.0.3" />
<action application="export" data="sip_secure_media=true"/>
<action application="bridge"
data="sofia/sip.evolutiontel.net/0631000006@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/0631000006@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/0631000006@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 <jim@evolutiontel.net> wrote:

[jason at jasonjgw.net]

Jim Burke <jim@evolutiontel.net> wrote:

[jim at evolutiontel.net]

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.

Regards,


On Tue, May 26, 2009 at 4:49 PM, Jason White <jason@jasonjgw.net> wrote:

[jason at jasonjgw.net]

Jim Burke <jim@evolutiontel.net> wrote:

[jim at evolutiontel.net]

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 <jason@jasonjgw.net> wrote:

[brian at freeswitch.org]

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: