Folks,

 

A simple clarification on RFC4568  usage.

 

User [EMAIL PROTECTED] wants to make a call(audio/video) to
[EMAIL PROTECTED] Alice would like media between Alice&Bob to be
encrypted, but would like the call to go through even if the encryption
between Alice&Bob is not possible. I am interested in figuring out how
the SDP exchange between Alice and Bob would proceed, for the two cases:

1. Bob supports encryption

2. Bob does not support encryption.

 

Various Options which I can think of are:

 

1. Alice sends INVITE to bob with SDP

   m = audio 30000 RTP/SAVP 0 

    a = crypto ....

   m = video 30000 RTP/SAVP 32

    a = crypto....

 

   If bob supports encryption no problem.

 

   If bob does not support encryption or specifically if it does not
support RTP/SAVP profile it will be send back an OK with following SDP

   m=audio 0  RTP/SAVP0

   a=inactive

   m = video 0 RTP/SAVP

   a=inactive

 

 At this point Alice does not know that bob does not support SAVP or if
there is something else wrong with the crypto parameters.  Is Alice
supposed to send another RE-INVITE with RTP/AVP profile ?

 

2. Alice sends an INVITE to bob with SDP

   m=audio 30000 RTP/AVP 0

   m=video 30002 RTP/AVP 32

   m =audio 30004 RTP/SAVP 0

   a = crypto: xxxx

  m=video 30006 RTP/SAVP 32

   a=crypto: xxxxx

 

  In this case, if bob does not support encryption he could pick up the
right two streams ( maybe). However, if bob supports encryption and
a=crypto attribute how does he know that 

m=audio 30000 RTP/AVP 0

and 

m=audio 30004 RTP/SAVP 0 

really refer to the same media stream.

 

 

3. Alice sends an INVITE to bob with SDP 

 

   m = audio 30000 RTP/SAVP 0 

    a = crypto ....

   m = video 30000 RTP/SAVP 32

    a = crypto....

 

And bobs UA sends a 4xx media unacceptable message, and alice tries
again without encryption. 

 

 

Your comments will be helpful.

 

thanks

Arun

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to