RE: [MMUSIC] Modified Proposal for Capability Negotiations

["Francois Audet" <[e-mail]>]

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

> -----Original Message-----
> From: Even, Roni [mailto:[e-mail]] 
> Sent: Tuesday, January 23, 2007 06:29
> To: Stach, Thomas; Colin Perkins; Robert R. Gilman
> Cc: [e-mail]
> Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations
> 
> 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 
> 
> 
> > -----Original Message-----
> > From: Stach, Thomas [mailto:[e-mail]]
> > Sent: Tuesday, January 23, 2007 3:41 PM
> > To: Colin Perkins; Robert R. Gilman
> > Cc: [e-mail]
> > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations
> > 
> > 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
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

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