[Freeswitch-users] Secure RTP

[Jim Burke]

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 at 192.168.0.3" />
        <action application="export" data="sip_secure_media=true"/>
        <action application="bridge"
data="sofia/sip.evolutiontel.net/0631000006 at 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 at 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 at 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 at 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 <brian at 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
>> brian at freeswitch.org
>> -- Meet us at ClueCon!  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
>>
>>
>