Subject: [MMUSIC] Modified Proposal for Capability Negotiations

From: "Robert R. Gilman" <[email-masked]>
Date: Tue, 16 Jan 2007 17:08:17 -0700

I've been playing with a means to make the cmed attribute line independent
of payload types, so it can be use at the session level or media level to
define media encodings.  These can be combined with transport protocols
at the session or media levels, and payload types at the media level.
Here's an approach that doesn't simply replicate the existing m-line in a
cmed attribute.  It builds up the capabilities from mime type/subtypes,
encoding parameters, and format parameters.  Note that the cenc and cfmt
lines are tied directly into the subtypes listed in the cmed line via the
subtype ordinal; they are implicitly incorporated in the pcfg attribute
by reference to their subtype ordinal(s).  One of the advantages of doing
this binding early is that an endpoint can offer a particular codec with
different format parameters (e.g., G.729 and G.729B).

Define/redefine the following new attributes:

     a=cmed:<first subtype ordinal> <mimetype> <list of mime subtypes>
	This line defines the set of codecs supported, and assigns
	an ordinal to each codec.  The codecs are referenced via their
	ordinals in  pcfg or acfg lines (via the m= parameter), and in
	cenc and cfmt attributes.
	If the first subtype ordinal is 's', say, the the first mime
         subtype corresponds to "subtyp s", the next to "s+1", and so on.
       example: a=cmed:1 PCMU G729 G729 iLBC events
             ; PCMU=1, G729=2, G729=3 iLBC=4, events=5

     a=ctrpr:<first transport ordinal> <list of transport protocols>
	This line defines the transport protocols/profiles supported;
	the pcfg line will refer to one of these via "p="
       example: a=ctrpr:1 RTP/AVP RTP/SAVP  => RTP/AVP=1 RTP/SAVP=2

     a=cenc:<subtype ordinal> <clock rate> [/<encoding parameters>]
	This line defines encoding attributes for the specified mime subtype.
	It is effectively incorporated as part of the codec with the specified
	ordinal.
       example: a=cenc:4 8000         ;sample rate for iLBC

     a=cfmt:<subtype ordinal> <format-specific parameters>
	This line defines format parameters for the specified mime subtype.
	It is effectively incorporated as part of the codec with the specified
	ordinal.
       example: a=cfmt:2 annexb:no    ;codec 2 doesn't support comfort noise

     a=cptmap:<map ordinal> <list of <subtype number>:<RTP payload type> pairs>
	This line defines the payload type(s) to be used with a particular
	configuration and referenced via "ptm=".  It may only be used by
         offered configurations, not latent configurations.
       example: a=cptmap:1 2:99 3:100   ; maps G.729 to PT 99, iLBC to PT 100

The remaining attributes (pcfg, acfg, capar) are defined as in Flemming's draft:
<draft-ietf-mmusic-sdp-capability-negotiation-00.txt>.

Then we might have an offer like the following.  This announces support
for 4 audio codecs (G.711mu-law, G.729, G.729B, iLBC) and in-band telephony
events for DTMF and Flash.
     ... (skipping over initial session lines)
1)    a=cmed:1 audio PCMU G729 G729 iLBC events
2)    a=cenc:4 8000                           ;iLBC with 8K sample rate
3)    a=ctrpr:1 RTP/AVP RTP/SAVP              ;transport profiles
4)    a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
5)    a=cfmt:2 annexb:no                      ;no comfort noise for G.729
6)    a=cfmt:5 0-15,16                        ;DTMF plus flash events
7)    a=pcfg:1 m=3,5|4,5 t=1                  ;a latent AVP capset
8)    a=pcfg:2 m=3,5|4,5 t=2 a=1              ;a latent SAVP capset
9)    m=audio 22222 AVT/RTP 0 18 100         ; standard audio line
10)   a=rtpmap:100 events
11)   a=fmt:100 0-15
12)   a=cptmap:1 1:101 2:102 5:103
13)   a=pcfg:3 m=1,5|2,5 p=2 a=1 ptm=1         ;(SRTP option)

Notes:
1)  This cmed line defines a set of audio codecs numbered 1-5.
2)  This cenc line defines adds encoding rate information for codec 3.
3)  This ctpr line defines two transport profiles numbered 1-2.
4)  This capar line defines an SDES crypto attribute.
5)  This cfmt line defines format parameters for codec 3 (G.729)
6)  This cfmt line defines the telephony event parameters for "codec 5",
     the telephony events.
7)  This pcfg line defines a latent AVP capset with any one of the four
     audio codecs plus DTMF telephony events.
8)  This pcfg line defines a latent SAVP capset with the same combinations
     of codecs/tlephony events.
9)  This is the conventional media line for audio with G.711mu-law, G.729B,
     and a dynamic payload type.
10) "Traditional" SDP for backward compatibility.
11) "Traditional" SDP for backward compatibility.
9)-11) In case the receiver understands capability negotiation, but wishes to
        choose the AVT/RTP offer rather than encryption, we define
        that the m= line defines "pcfg:0", "cptmap:0", transport type "0", and
        the media codecs are assigned the next codec ordinals following those
        defined at the session level (codecs defined at the media level via cmed
        attributes will be numbered following those defined on the m=line).
        Thus, the m= line and the following rtpmap and fmtp lines are equivalent
        to:
	a=cmed:6 PCMU G729 event
	a=cptmap:0 8:100
	a=pcfg:0 m=6,7,8 p=0 ptm=0
        Any pcfg: line at the media level may refer to the codecs and transports
        defined by the current m= line.
12) This line provides the payload types for each cmed codec for this media
     stream.  The payload types are chosen, in this case, so that the receiver
     can use them to tell which choices the answerer made if media is received
     by the offeror before the answer arrives.
13) This line specifies an alternative media stream using SRTP.
     p=2 invokes the second transport protocol (RTP/SAVP) from the ctrpr
         line.
     a=1 identifies the SDES crypto attribute
     ptm=1 identifies the payload map.  I've used "1" to identify the
           entire line, but we could use numbers to identify each mapping,
           as ptm=1,2,3
     Note that there are no references to the cfmt or cenc attributes - they're
     always attached to their respective media subtypes.

Given an offer in the above form, a endpoint that doesn't understand the capneg
attributes will respond with the usual m= line and attributes.  If the endpoint
does understand capneg, it is expected to reply with the m=line and the
particular configuration it has chosen in an acfg attribute.  If it chooses the
unencrypted media as described above with PCMU encoding, it might follow the m=
line with
	a=acfg:0 m=6,8 p=0 ptm=0
In either case, the answering endpoint can include latent configurations as
well.

In the simple case that the offeror doesn't want to offer any latent media
configurations, but does want to offer the SRTP alternative, the SDP could be
reduced to the following:
     ... (skipping over initial session lines)
9)    m=audio 22222 AVT/RTP 0 18 100         ; standard audio line
10)   a=rtpmap:100 events
11)   a=fmt:100 0-15
3)    a=ctrpr:1 RTP/SAVP                      ;transport profile
4)    a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
12)   a=cptmap:1 1:101 2:102 3:103
13)   a=pcfg:1 m=1,3|2,3 p=1 a=1 ptm=1         ;(SRTP option)

Line 12, and the ptm=1 parameter in line 13, could be eliminated if the
offeror doesn't need to use the payload types to decide early media can
be rendered.

My apologies for numbering errors, etc.  Please reply with any comments,
corrections, additions, etc.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Jan 2007 08:44:32 +0000

I like this... but it's a big change to the SDP semantics.

If we were starting from scratch, or weren't under such time  
pressure, it would definitely be worth serious configuration. For the  
current design team, where we need something ready for working group  
last call before the Prague meeting, I'm concerned that we need  
something closer to the current semantics.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 23 Jan 2007 14:41:06 +0100

Colin, Bob,

I like the proposal as well since it clearly separates media
capabilities from the rest of the attributes in the a=capar: line that
Fleming's original proposal had defined as container for all attribute
lines.  

I also share the concern about time pressure. 
So, what about moving the media related work to a separate document?
This would leave the basic negotiation framework, extensibility and a
solution for best effort SRTP for an initial step.
With this limited scope the document could be ready for a last call
quite soon.

Regards
Thomas

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Tuesday, January 23, 2007 9:45 AM
> To: Robert R. Gilman
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Modified Proposal for Capability Negotiations
> 
> > encoding parameters, and format parameters.  Note that the 
> cenc and  
> > cfmt
> > by reference to their subtype ordinal(s).  One of the 
> advantages of  
> > doing
> > this binding early is that an endpoint can offer a 
> particular codec  
> > with
> > 5)    a=cfmt:2 annexb:no                      ;no comfort 
> noise for  
> > G.729
> > 9)  This is the conventional media line for audio with 
> G.711mu-law,  
> > G.729B,
> > 9)-11) In case the receiver understands capability 
> negotiation, but  
> > wishes to
> > does understand capneg, it is expected to reply with the 
> m=line and  
> > the
> > particular configuration it has chosen in an acfg 
> attribute.  If it  
> > chooses the
> > Line 12, and the ptm=1 parameter in line 13, could be 
> eliminated if  
> > the
> > offeror doesn't need to use the payload types to decide 
> early media  
> > can
> > be rendered.
> >

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 23 Jan 2007 16:28:34 +0200

Hi,
I am not sure what you mean about the media related work. Everything
here is about media.
Bob tried to address a way to support session level attributes so that
they can be mapped to a PT in the media line.

As for the timeline, I have not heard from the design team any concerns
about time. The design team charter agreed in San Diego was to look at
general solution. 

Being able to know the media capabilities of the remote side separately
from the current negotiated media session is already a problem for
changing codec in mid calls. So it is not only the issue of best-effort
SRTP

Roni Even 

> From: Stach, Thomas [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2007 3:41 PM
> To: Colin Perkins; Robert R. Gilman
> Cc: [email-masked]
> Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations
> 
> Colin, Bob,
> 
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|
> > > 1:32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|
> > > 1:32

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 23 Jan 2007 16:56:48 +0200

Bob,
Comments
You use the pcfg with an ordinance number in lines 7, 8, 13. The current
draft does not have ordinance number and all pcfgs are after the media m
line by preference order. Why change

Your usage of the pcfg in the document is different and not needed. The
order of AVP or SAVP will be done by using two pcfg after the m line one
with p=1 for AVP and the other with p=2 for SAVP, the order is the
preference.

In line 12 where are the PT mapping for G729 and G729B

Some nits

2)  This cenc line defines adds encoding rate information for codec 3. -
you mean 4

5)  This cfmt line defines format parameters for codec 3 (G.729) - you
mean 2

Roni

> From: Robert R. Gilman [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2007 2:08 AM
> To: [email-masked]
> Subject: [MMUSIC] Modified Proposal for Capability Negotiations
> 
>      a=cptmap:<map ordinal> <list of <subtype number>:<RTP payload
type>
> pairs>
>        example: a=cptmap:1 2:99 3:100   ; maps G.729 to PT 99, iLBC to
PT
> 100
> 
> The remaining attributes (pcfg, acfg, capar) are defined as in
Flemming's
> draft:
> 9)-11) In case the receiver understands capability negotiation, but
wishes
> to
>         that the m= line defines "pcfg:0", "cptmap:0", transport type
"0",
> and
>         the media codecs are assigned the next codec ordinals
following
> those
>         defined at the session level (codecs defined at the media
level
> via cmed
>      Note that there are no references to the cfmt or cenc attributes
-
> they're
> Given an offer in the above form, a endpoint that doesn't understand
the
> capneg
> unencrypted media as described above with PCMU encoding, it might
follow
> the m=
> line with
> 	a=acfg:0 m=6,8 p=0 ptm=0
> In either case, the answering endpoint can include latent
configurations
> as
> configurations, but does want to offer the SRTP alternative, the SDP
could
> be

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 23 Jan 2007 13:35:07 -0600

It was clearly agreed in San Diego AND in Montreal, that time was a huge
concern for best-effort SRTP. 

> From: Even, Roni [mailto:[email-masked]] 
> Sent: Tuesday, January 23, 2007 06:29
> To: Stach, Thomas; Colin Perkins; Robert R. Gilman
> Cc: [email-masked]
> I am not sure what you mean about the media related work. 
> Everything here is about media.
> Bob tried to address a way to support session level 
> attributes so that they can be mapped to a PT in the media line.
> 
> As for the timeline, I have not heard from the design team 
> any concerns about time. The design team charter agreed in 
> San Diego was to look at general solution. 
> 
> Being able to know the media capabilities of the remote side 
> separately from the current negotiated media session is 
> already a problem for changing codec in mid calls. So it is 
> not only the issue of best-effort SRTP
> 
> Roni Even 
> 
> 
> > > > I've been playing with a means to make the cmed attribute line 
> > > > independent of payload types, so it can be use at the session 
> > > > level or media level to define media encodings.  These can be 
> > > > combined with transport protocols at the session or 
> media levels, 
> > > > and payload types at the
> > > media level.
> > > > Here's an approach that doesn't simply replicate the 
> existing m- 
> > > > line in a cmed attribute.  It builds up the 
> capabilities from mime 
> > > > type/ subtypes, encoding parameters, and format 
> parameters.  Note 
> > > > that the
> > > cenc and
> > > > cfmt
> > > > lines are tied directly into the subtypes listed in the 
> cmed line 
> > > > via the subtype ordinal; they are implicitly 
> incorporated in the 
> > > > pcfg attribute by reference to their subtype 
> ordinal(s).  One of 
> > > > the
> > > advantages of
> > > > doing
> > > >         subtype corresponds to "subtyp s", the next to 
> "s+1", and 
> > > > so on.
> > > > 	It is effectively incorporated as part of the 
> codec with the 
> > > > specified
> > > > 	ordinal.
> > > > 	It is effectively incorporated as part of the 
> codec with the 
> > > > specified
> > > > 	ordinal.
> > > > type> pairs>
> > > >       example: a=cptmap:1 2:99 3:100   ; maps G.729 to 
> PT 99, iLBC
> > > > to PT 100
> > > >
> > > > Flemming's draft:
> > > > Then we might have an offer like the following.  This announces 
> > > > support for 4 audio codecs (G.711mu-law, G.729, G.729B, 
> iLBC) and 
> > > > in-band telephony events for DTMF and Flash.
> > > > 2)    a=cenc:4 8000                           ;iLBC 
> with 8K sample
> > > > rate
> > > > 7)  This pcfg line defines a latent AVP capset with any 
> one of the 
> > > > four
> > > > following those
> > > > level via cmed
> > > >        attributes will be numbered following those 
> defined on the 
> > > > m=line).
> > > >        Thus, the m= line and the following rtpmap and 
> fmtp lines 
> > > > are equivalent
> > > >        to:
> > > > 	a=cmed:6 PCMU G729 event
> > > > 	a=cptmap:0 8:100
> > > >        Any pcfg: line at the media level may refer to 
> the codecs 
> > > > and transports
> > > > 12) This line provides the payload types for each cmed 
> codec for 
> > > > this media
> > > >     stream.  The payload types are chosen, in this 
> case, so that 
> > > > the receiver
> > > >     can use them to tell which choices the answerer 
> made if media 
> > > > is received
> > > >     p=2 invokes the second transport protocol 
> (RTP/SAVP) from the 
> > > > ctrpr
> > > >         line.
> > > >           entire line, but we could use numbers to 
> identify each 
> > > > mapping,
> > > >           as ptm=1,2,3
> > > > Given an offer in the above form, a endpoint that doesn't 
> > > > understand the capneg attributes will respond with the usual m= 
> > > > line and attributes.  If the endpoint does understand 
> capneg, it 
> > > > is expected to reply with the
> > > m=line and
> > > > the
> > > > follow the m= line with
> > > > configurations as well.
> > > > In the simple case that the offeror doesn't want to offer any 
> > > > latent media configurations, but does want to offer the SRTP 
> > > > alternative, the SDP could be reduced to the following:
> > > > My apologies for numbering errors, etc.  Please reply with any 
> > > > comments, corrections, additions, etc.
> > > > -Bob

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 24 Jan 2007 08:42:10 +0200

Francois,
I am sorry if did not understand what I meant. My meaning was that the
design team did not show any concerns about being able to finish in
time.
Roni

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2007 9:35 PM
> To: Even, Roni; Stach, Thomas; Colin Perkins; Robert R. Gilman
> Cc: [email-masked]
> > > > >        that the m= line defines "pcfg:0", "cptmap:0",
transport
> > > > > type "0", and
> > > > >     ptm=1 identifies the payload map.  I've used "1" to
identify