Subject: [MMUSIC] Session-level Parameters in Cap Negotiation

From: "Robert R. Gilman" <[email-masked]>
Date: Wed, 10 Jan 2007 14:55:23 -0700

In yesterday's telephone conference on SDP capabilities negotiation, discussion
centered on the needs and uses of capability expressions at the session level
verses use of those expressions at the media level.  Refer to the current
draft <draft-ietf-mmusic-sdp-capability-negotiation-00.txt> for definition
of attributes not defined in this note.  I volunteered to put forward a straw-
man set of examples about how this might work - so here's a first cut at it.
Comments, suggestions and alternatives are solicited.

(We also discussed changing the transport protocol parameter identifier from
"p=" to "t=" in the pcfg attribute, but I've left it as "p=" here so it matches
the current version of the draft.  In addition, the cver attribute may become
a special option tag, e.g. cvern, to be used in the creq/csup attributes as a
shorthand for "all attributes in version n".)

To start, consider the example in Section 2.1 of the draft:
            v=0
            o=- 25678 753849 IN IP4 128.96.41.1
            s=
            c=IN IP4 128.96.41.1
            t=0 0
            m=audio 3456 RTP/AVP 0 18
            a=cver:0
            a=cmed:1 audio RTP/AVP 0 18 96
            a=ctrpr:1 RTP/SAVP
            a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
            a=capar:2 a=rtpmap:96 iLBC/8000
            a=pcfg: m=1,2|3 p=1 a=1,2
            a=pcfg: m=1,2|3 a=2

This SDP represents a conventional offer of PCMU or G729, along with capability
attibutes to offer PCMU, G729 and/or iLBC coding, with or without SRTP.
Now, if the offeror wishes to offer RTP/SAVP or RTP/AVP with different payload
types so that it may easily decide whether or not to render early media before
it has received the other party's transmit key, for example, then it can send
the following offer:
            v=0
            o=- 25678 753849 IN IP4 128.96.41.1
            s=
            c=IN IP4 128.96.41.1
            t=0 0
            m=audio 3456 RTP/AVP 0 18
            a=cver:0
            a=cmed:1 audio RTP/AVP 0 18 96
            a=cmed:4 audio RTP/SAVP 97 98 99
            a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
            a=capar:2 a=rtpmap:96 iLBC/8000
            a=capar:3 a=rtpmap:97 PCMU/8000
            a=capar:4 a=rtpmap:98 G729/8000
            a=capar:5 a=rtpmap:99 iLBC/8000
            a=pcfg: m=4,5|6 a=1,3,4,5
            a=pcfg: m=1,2|3 a=2
This type of solution will also be required in cases where multiple media
streams carry the same encoding(s) but separation by payload type is desired.

Now, consider what might happen if the cap negotiation attributes are
permitted to appear at the session level.  This has a couple of potential
advantages:
	1. Attributes may be reused in multiple media streams.
	2. Stream configurations may be presented for future use independent
	   of any stream in the present offer.
	3. The resulting SDP may be more compact.
Here's an example similar to the above, but with the encrypted media stream
offer left for a future negotiation, and a second (unencrypted) audio stream
using iLBC only.  The second channel has the cap negotiation elements at the
media level since they're not reused.

            v=0
            o=- 25678 753849 IN IP4 128.96.41.1
            s=
            c=IN IP4 128.96.41.1
            t=0 0
            a=cver:0
            a=cmed:1 audio RTP/AVP 0 18 96
            a=ctrpr:1 RTP/SAVP
            a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
            a=capar:2 a=rtpmap:96 iLBC/8000
            a=pcfg: m=1,2|3 p=1 a=1,2
            m=audio 3456 RTP/AVP 0 18
            a=pcfg: m=1,2|3 a=2
            m= audio 3458 RTP/AVP 0
            a=cmed:4 audio RTP/AVP 97
            a=capar: a=rtpmap:97 iLBC/8000
            a=pcfg: m=4 a=3

This illustrates a problem with payload formats versus RTP payload types.
Ideally, the media lines (or at least the cmed attributes) should describe
the payload format(s) and the RTP payload types should be defined within each
media stream.  One proposal is to specify the cmed lines using mime subtypes,
with a new attribute for mapping from mime subtype to payload type at the media
level.  Here's the previous example with that change, as well as a second option
for the first media stream.  We've defined a new cap negotiation attribute
called cptmap to carry the PT mapping, and a cmed parameter, ptm, to specify
the mapping attribute(s) to use:
            v=0
            o=- 25678 753849 IN IP4 128.96.41.1
            s=
            c=IN IP4 128.96.41.1
            t=0 0
            a=cver:0
            a=cmed:1 audio RTP/AVP pcmu/8000 g729/8000 ilbc/8000
            a=ctrpr:1 RTP/SAVP
            a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
            a=pcfg: m=1,2|3 p=1 a=1,2
            m=audio 3456 RTP/AVP 0 18
            a=cptmap:1 0=pcmu 18=g729 96=ilbc
            a=pcfg: m=1,2|3 ptm=1,2|3
            a=pcfg: m=3 ptm=3         <- iLBC-only option, with PT=96.
            m= audio 3458 RTP/AVP 0
            a=cptmap:4 97=ilbc
            a=pcfg: m=4 a=3 ptm=4
Note that cptmap is not needed for latent pcfg lines - the mapping will be
specified, if necessary, when/if a media stream using the capability is
actually offered.  Note that we have avoided the use of rtpmap attributes by
including their content in the cmed line, but we've ignored the use of fmtp
attributes, leaving them to the media level.

Rather than use the mime subtypes explicitly, we could revert to the use of
the "default" payload types in cmed attributes, as in the m= lines.  But, when
the lines appear at the session level, we would interpret the payload types as
media formats only (with the help of rtpmap attributes for codecs with no fixed
payload type.)  RFC 4566 specifies the rtpmap attribute as a media-level-only
parameter, hence it may be necessary to merge the rtpmap information into the
cmed line.  If we do this, the cmed:1 line in the above example could become
something like
            a=cmed:1 audio RTP/AVP 0 18 96:iLBC/8000
A cptmap attribute could still be used to map the media types to specific
payloads for each media stream, if necessary.  In this case (from the above
example), it could take a form something like
            a=cptmap:1 97=96
in the second media stream (it's not needed in the first stream since the
"default" payload type is used.  Clearly, this could use better punctuation.
So as to avoid an ordering problem with fmtp attributes,  I'd suggest they
must use the PT numbers that appear in the cmed and/or media lines, not the
mapped-to PTs.

The ability to map payload types could prove useful outside of the capability
negotiation realm, but it's not necessary.  The same effect can be achieved
with the use of an rtpmap line per payload with little extra cost.

Comments, suggestions, and alternatives are welcome.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

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