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

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