RE: [MMUSIC] Modified Proposal for Capability Negotiations

["Even, Roni" <[e-mail]>]

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

> -----Original Message-----
> From: Robert R. Gilman [mailto:[e-mail]]
> Sent: Wednesday, January 17, 2007 2:08 AM
> To: [e-mail]
> Subject: [MMUSIC] Modified Proposal for Capability Negotiations
> 
> 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

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