[Freeswitch-users] Secure RTP

[Jim Burke]

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
>
>