Subject: [MMUSIC] Session Attributes in Capability Negotiation

From: Matt Lepinski <[email-masked]>
Date: Mon, 12 Feb 2007 14:09:15 -0500

I was reading through the -01 version of the Capability Negotiation 
draft and I wanted to make sure that I understand the current semantics 
for session level attributes. I've included some examples which seem 
reasonable (to me). Please let me know if my understanding of the 
current semantics is incorrect.

(Note: As per Flemming's email dated 02/12/07, I am using "acap" instead 
of "capar" and "tcap" instead of "ctrpr" --- which is much easier for me 
to keep straight when writing SDP by hand.)

Example 1: I believe the following SDP will offer a single audio stream 
using "Best-Effort" SRTP and Mikey (at the session level).

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 1
a=creq: v0
a=acap:1 a=key-mgmt:mikey ABAC...
m=audio 3456 RTP/AVP 0
a=tcap:1 RTP/SAVP RTP/AVP
a=pcfg:1 t=1 a=1

(Note: I think we had discussed at some point whether I need to include 
"a=pcfg:2 t=2" to indicate that I prefer SAVP over AVP ... I think the 
consensus was that I don't need the second "pcfg" line, but I'm not 
certain).

Example 2: The following is an offer for a single "Best-Effort" SRTP 
audio stream where Mikey is preferred (e.g. offerer would like to do a 
Diffie-Hellman exchange), but the use of SDP Security Descriptions is 
acceptable.

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 2
a=creq: v0
a=acap:1 a=key-mgmt:mikey ABAC...
m=audio 3456 RTP/AVP 0
a=tcap:1 RTP/SAVP RTP/AVP
a=acap:2 a=crypto:1 AES_CM_128...
a=pcfg:1 t=1 a=1
a=pcfg:2 t=1 a=2

Example 3: Where this gets interesting is if I want to offer two 
"Best-Effort" SRTP audio streams.

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 3
a=creq: v0
a=acap:1 a=key-mgmt:mikey ABAC...
a=tcap:1 RTP/SAVP RTP/AVP
m=audio 3456 RTP/AVP 0
a=acap:2 a=crypto:1 AES_CM_128...
a=pcfg:1 t=1 a=1
a=pcfg:2 t=1 a=2
m=audio 4680 RTP/AVP 0 18
a=acap:3 a=crypto:1 AES_CM_128...
a=pcfg:1 t=1 a=1
a=pcfg:2 t=1 a=3

(Note: I think we discussed at some point whether I needed to repeat the 
"a=tcap" line once for each media stream and I believe the consensus was 
that it is acceptable to avoid repetition by placing the "a=tcap" line 
at the session level)

My understanding of the semantics is that if the answerer selected 
potential configuration #1 (pcfg:1) for each media stream, then this is 
equivalent to case where the offerer provided the following offer:

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 3
a=key-mgmt:mikey ABAC...
m=audio 3456 RTP/AVP 0
m=audio 4680 RTP/AVP 0 18

Similarly, if the answerer selected pcfg:1 for the first media stream 
and pcfg:2 for the second media stream, then this is equivalent to the 
case where the offerer provided the following offer:

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 3
a=key-mgmt:mikey ABAC...
m=audio 3456 RTP/AVP 0
m=audio 4680 RTP/AVP 0 18
a=crypto:1 AES_CM_128...

Now it's possible that this latter case is undesirable (if the answerer 
supports Mikey, why isn't he willing to use Mikey for both streams???). 
My understanding is that in a future extension to the Capability 
Negotiation framework we might have the ability to prohibit certain 
combinations of pcfg lines (e.g. don't accept pcfg:1 for the first 
stream and pcfg:2 for the second stream). However, my understanding is 
that for the time being it is the responsibility of the answerer not to 
select "bad" combinations of session  and media stream attributes.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Feb 2007 17:32:29 -0500

Matt Lepinski wrote:
> draft and I wanted to make sure that I understand the current 
> semantics for session level attributes. I've included some examples 
> which seem reasonable (to me). Please let me know if my understanding 
> of the current semantics is incorrect.
>
> (Note: As per Flemming's email dated 02/12/07, I am using "acap" 
> instead of "capar" and "tcap" instead of "ctrpr" --- which is much 
> easier for me to keep straight when writing SDP by hand.)
>
> Example 1: I believe the following SDP will offer a single audio 
> stream using "Best-Effort" SRTP and Mikey (at the session level).
>
> v=0
> (Note: I think we had discussed at some point whether I need to 
> include "a=pcfg:2 t=2" to indicate that I prefer SAVP over AVP ... I 
> think the consensus was that I don't need the second "pcfg" line, but 
> I'm not certain).
That's correct.
> a=acap:2 a=crypto:1 AES_CM_128...
Looks good.
> (Note: I think we discussed at some point whether I needed to repeat 
> the "a=tcap" line once for each media stream and I believe the 
> consensus was that it is acceptable to avoid repetition by placing the 
> "a=tcap" line at the session level)
Correct.
> potential configuration #1 (pcfg:1) for each media stream, then this 
> is equivalent to case where the offerer provided the following offer:
>
> v=0
Right (except you have to replace "RTP/AVP" with "RTP/SAVP" in both "m=" 
lines)
> m=audio 4680 RTP/AVP 0 18
Right (except you have to replace "RTP/AVP" with "RTP/SAVP" in both "m=" 
lines)
> Now it's possible that this latter case is undesirable (if the 
> answerer supports Mikey, why isn't he willing to use Mikey for both 
> streams???). My understanding is that in a future extension to the 
> Capability Negotiation framework we might have the ability to prohibit 
> certain combinations of pcfg lines (e.g. don't accept pcfg:1 for the 
> first stream and pcfg:2 for the second stream). However, my 
> understanding is that for the time being it is the responsibility of 
> the answerer not to select "bad" combinations of session  and media 
> stream attributes.
>
That's correct, although I'm not sure this particular example is "bad" 
(at least I don't see anything forbidden in it, unless there is some 
MIKEY rule I'm not aware of).

-- Flemming