[MMUSIC] Modified Proposal for Capability Negotiations

["Robert R. Gilman" <[e-mail]>]

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