Re: [MMUSIC] Modified Proposal for Capability Negotiations

[Colin Perkins <[e-mail]>]

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



On 17 Jan 2007, at 00:08, Robert R. Gilman wrote:
> 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       [e-mail]      [phone]
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic

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



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