RE: [MMUSIC] Modified Proposal for Capability Negotiations

["Stach, Thomas" <[e-mail]>]

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:[e-mail]] 
> Sent: Tuesday, January 23, 2007 9:45 AM
> To: Robert R. Gilman
> Cc: [e-mail]
> Subject: Re: [MMUSIC] Modified Proposal for Capability Negotiations
> 
> 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
> 

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