Subject: [Sip] SDES RFC4568 usage clarification

From: "Arun Punj" <[email-masked]>
Date: Tue, 23 Oct 2007 10:09:57 -0500

Folks,

A simple clarification on RFC4568  usage.

User [email-masked] wants to make a call(audio/video) to
[email-masked]. 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 23 Oct 2007 11:15:59 -0700

> -----Original Message-----
> From: Arun Punj [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2007 8:10 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: SDES RFC4568 usage clarification
> 
> Folks,
> 
>  
> 
> [email-masked]. 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.

draft-ietf-mmusic-sdp-capability-negotiation solves that exact problem,
and works with forking (many of your examples below will not work as 
desired with forking).

http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation 

-d

> I am 
> interested in figuring out how the SDP exchange between Alice 
> and Bob would proceed, for the two cases:
> 
>    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 ?
> 
>  
> 
>   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 
> 
> And bobs UA sends a 4xx media unacceptable message, and alice 
> tries again without encryption. 
> 
>  
> 
>  
>