Subject: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

From: "Joe Stone (joestone)" <[email-masked]>
Date: Fri, 1 Feb 2008 13:39:47 -0800

How would I express RFC 2198 redundancy using the Media Encoding
Parameter Capability Attribute? I'm looking for a potential
configuration which is equivalent to,
 
       m=audio 12345 RTP/AVP 121 0 5
       a=rtpmap:121 red/8000/1
       a=fmtp:121 0/5

With the "red" media format, the "a=fmtp" attribute <format specific
parameters> reference the payload types of the redundant encodings.
However, if the redundant encodings don't appear as part of the "m="
field, the payload types are only assigned as part of the potential
configuration (and are not assigned as part of a latent configuration).
 
Effectively, I'm after,
 
    a=mcap:1 audio RED PCMU DVI4
    a=fcap:1 PCMU/DVI4
 
however, the "a=fmtp" attribute (as defined in conjunction with the
"red" media format) doesn't allow for the use of redundant encoding
names, only redundant encoding payload types.
 
You could define the "a=fcap" attribute to mandate the use of a
<med-cap-num> in place of payload types. For example,
 
    a=mcap:1 audio RED PCMU PCMU
    a=fcap:1 2/3
 
would be equivalent to the "a=fcap" attribute above.
 
How do you handle SDP attributes other than "a=fmtp"? Do you need to
extend the Media Capabilities Negotiation framework with each new
attribute? RFC 3407 (which you're hoping to obsolete) allows for any SDP
attribute to be expressed as part of the latent configuration,
 
    a=cdsc:1 image udptl t38
    a=cpar:a=T38FaxVersion:0
    a=cpar:a=T38FaxRateManagement:transferredTCF
    a=cpar:a=T38FaxMaxDatagram:160
    a=cpar:a=T38FaxUdpEc:t38UDPRedundancy
 
Joe
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Fri, 1 Feb 2008 14:19:18 -0800

[I corrected one typo and attempted to clarify the last paragraph]

 
 
Effectively, I'm after,

 

 
How do you handle SDP attributes other than "a=fmtp" which involve
payload types which don't appear in the "m=" field? Do you need to
extend the Media Capabilities Negotiation framework with each new
attribute? RFC 3407 (which you're hoping to obsolete) allows for any SDP
attribute to be expressed as part of the latent configuration,
 
    a=cdsc:1 audio RTP/AVP 0 8 96 
    a=cpar:a=rtpmap:96 PCMU/8000
    a=cpar:a=gpmd:96 vbd=yes
    a=cdsc:4 image udptl t38
    a=cpar:a=T38FaxVersion:0
    a=cpar:a=T38FaxRateManagement:transferredTCF
    a=cpar:a=T38FaxMaxDatagram:160
    a=cpar:a=T38FaxUdpEc:t38UDPRedundancy
 
Joe

---

From: Bob Gilman <[email-masked]>
Date: Fri, 01 Feb 2008 22:08:50 -0700

Joe-

Good observation.  It looks like we overlooked the use of payload types
in

the fmtp attribute for redundancy.  Do you know of other cases in which
a

payload type appears in an fmtp attribute?

For capabilities negotiation, I think we need a solution that preserves
the

use of the payload types in the fcap attribute.  The contents of an fmtp

attribute need not be understood by the SDP processing layer, and I
think

that should apply to the contents of fcap as well.  (It's bad enought we

permit fcap lines to be concatenated to form contents equivalent to a
single

fmtp line, but at least we need not understand the contents of the fcap

lines to do this.

I think the easiest solution may be to simply permit the use of the
payload

type parameters in the lcfg attribute (it's already available in the
pcfg

attribute, of course.  Then, the potential configuration equivalent to
your

example would be something like the following:

m=audio 12345 RTP/AVP 0

a=ecap:1,2,3 8000/1

a=fcap:1 0/5

a=pcfg:1 m=1,2,3 pt=1:121,2:0,3:5

A latent configuration would look much the same, but, of course, the

payload types could be changed when such a configuration was actually

offered.

I think you're correct that we would have to define a new capability

attribute for any attribute that referred to a payload type from the

media line, which is just what we did for rtpmap and fmtp attributes.

But, given the use of the pt parameters, we wouldn't have to worry about

payload types within the parameters of those attributes.  That is, for

the line in your example

a=fmtp:121 0/5

we need a capability attribute to replace the 121 payload type with a

media capability number, but we can leave the other payload types alone.

Does this seem like a satisfactory answer to the problem you posed?

-Bob

-------------------------------------------------------------

Bob Gilman [email-masked] 303 898 9780

Joe Stone (joestone) wrote:

[I corrected one typo and attempted to clarify the last
paragraph]

How would I express RFC 2198
redundancy using the Media Encoding Parameter Capability Attribute? I'm
looking for a potential configuration which is equivalent to,

m=audio 12345 RTP/AVP 121
0 5

a=rtpmap:121 red/8000/1

a=fmtp:121 0/5

With the "red" media
format, the "a=fmtp" attribute <format
specific parameters> reference the payload types of the redundant
encodings. However, if the redundant
encodings don't appear as part of the "m=" field, the payload types are
only assigned as part of the potential configuration (and are not
assigned as part of a latent configuration).

Effectively, I'm after,

a=mcap:1 audio RED
PCMU DVI4

a=fcap:1 PCMU/DVI4

however, the "a=fmtp" attribute
(as defined in conjunction with the "red" media format) doesn't allow
for the use of redundant encoding names, only redundant encoding
payload types.

You could define the "a=fcap"
attribute to mandate the use of a <med-cap-num> in place of
payload types. For example,

a=fcap:1 2/3

would be equivalent to the "a=fcap" attribute
above.

How do you handle SDP
attributes other than "a=fmtp" which involve payload types which don't appear in the
"m=" field? Do
you need to extend the Media Capabilities Negotiation framework with
each new attribute? RFC 3407 (which you're hoping to obsolete) allows
for any SDP attribute to be expressed as part of the latent
configuration,

a=cdsc:1 audio
RTP/AVP 0 8 96

a=cpar:a=gpmd:96
vbd=yes

a=cdsc:4 image udptl t38

a=cpar:a=T38FaxVersion:0

Joe

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Sat, 2 Feb 2008 08:39:58 -0800

Hi Bob,
 
[js] Comments in line...

________________________________

From: Bob Gilman [mailto:[email-masked]] 
Sent: Friday, February 01, 2008 11:09 PM
To: Joe Stone (joestone)
Cc: [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Joe-
 
[js] Not that I'm aware of.

[js] Understood.

   m=audio 12345 RTP/AVP 0

[js] I like that.
 
[js] I'm a little leery that different potential configurations (and
with the proposed change, different latent configurations) can bind the
same payload type (most likely a dynamic payload type) to different
media subtypes of the "a=mcap" attribute, correct? Conceivably, a single
"a=fcap" capability attribute could take on multiple meanings. 

[js] I'm referring to format-specific SDP attributes in general,
 
    a=<attribute>:<format> [<format specific parameters>]
 
[js] Yes, "a=rtpmap" and "a=fmtp" fall into this category. I'm asking
why we can't have a single capability attribute which accommodates all
SDP attributes of this form. For example,
 
    a=xcap:<med-cap-num-list> <attribute> <list of format parameters>
 
[js] V.152 with RFC 2198 redundancy, 
    m=audio 3456 RTP/AVP 18 96 97
    a=rtpmap:96 RED/8000
    a=fmtp:96 97/97
    a=rtpmap:97 PCMU/8000
    a=gpmd:97 vbd=yes

[js] becomes,

    a=mcap:1 audio G729 RED PCMU
    a=ecap:1,2,3 8000/1
    a=xcap:2 fmtp 97/97
    a=xcap:3 gpmd vbd=yes
    a=pcfg:1 m=1,2,3 pt=1:18,2:96,3:97

[js] Here you have a single capability attribute which is capable of
representing both the "a=fmtp" and "a=gpmd" SDP attributes (and, in
theory, all format-specific SDP attributes).

[js] I don't know about allowing multiple capability attributes (both in
the context of the "a=fcap" attribute and in the context of this more
general capability attribute) to be associated with the same
med-cap-num. You need to weigh the complexity of readability and
implementation with the savings of a few text characters.
Implementations need to deal with the case in which the same
format-specific parameter appears in more than one of the capability
attributes (possibly with different values) being concatenated. Which
value takes precedence? 

[js] Looks good.
 
-Bob

	

	With the "red" media format, the "a=fmtp" attribute <format
specific parameters> reference the payload types of the redundant
encodings. However, if the redundant encodings don't appear as part of
the "m=" field, the payload types are only assigned as part of the
potential configuration (and are not assigned as part of a latent
configuration).
	 
	Effectively, I'm after,

	however, the "a=fmtp" attribute (as defined in conjunction with
the "red" media format) doesn't allow for the use of redundant encoding
names, only redundant encoding payload types.

	 
	 
	How do you handle SDP attributes other than "a=fmtp" which
involve payload types which don't appear in the "m=" field? Do you need
to extend the Media Capabilities Negotiation framework with each new
attribute? RFC 3407 (which you're hoping to obsolete) allows for any SDP
attribute to be expressed as part of the latent configuration,

	Joe

________________________________

---

From: Bob Gilman <[email-masked]>
Date: Sat, 02 Feb 2008 16:25:23 -0700

Joe-
My replies are in-line below.  The idea of a generic "xcap" that
can be used for any attribute that is tied to a MIME subtype (e.g.,
via the payload type) seems better than defining individual cap
attributes for each present and future case.  Does anyone see a
problem with that?  I'm in the process of updating the draft for
the March meeting, so please let me know as soon as possible.
Thanks.
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

Joe Stone (joestone) wrote:
> Hi Bob,
>  
> [js] Comments in line...
> 
> ------------------------------------------------------------------------
> Good observation.  It looks like we overlooked the use of payload types in
> the fmtp attribute for redundancy.  Do you know of other cases in which a
> For capabilities negotiation, I think we need a solution that preserves the
> attribute need not be understood by the SDP processing layer, and I think
> permit fcap lines to be concatenated to form contents equivalent to a single
> I think the easiest solution may be to simply permit the use of the payload
> type parameters in the lcfg attribute (it's already available in the pcfg
> attribute, of course.  Then, the potential configuration equivalent to your
> same payload type (most likely a dynamic payload 
> type) to different media subtypes of the "a=mcap" attribute, correct? 
> Conceivably, a single "a=fcap" capability attribute could take on 
> multiple meanings.
[rrg]: Indeed, if one selected the payload types correctly (or
        erroneously :-)), one could use one fcap line to create options
        with different redundant encodings.  In the worst case, the
        offeror would have to wait for the answer before it could
        decode the received media.  We tried to provide the ability to
        define the configurations in such a way that the offeror could
        insure that it could decode early media correctly, based on the
        payload types.  But we don't require that the payload types all
        be unique across all potential configurations.  Sometimes I look
        at the AMR codec and wonder how many useful combinations there
        actually are, and if there are enough payload types to
        distinguish them all - especially if they are offered with and
        without encryption and different keying methods.
> theory, all format-specific SDP attributes).
[rrg]: Offhand, I don't see any problem with that.  It would sure
        protect us from having to invent new attributes to cover new (or
        (unrecognized) cases.
> attributes (possibly with different values) being concatenated. Which 
[rrg]: I think the concatenation isn't needed (or even used) in most
        simple cases.  We added it to reduce text for the cases like AMR
        where the number of combinations of options can be quite large.
        Granted, it's possible to mess things up, especially if one
        encodes by hand, and wind up with conflicting parameters assigned
        to one media capability, but we can't prevent that anyway.  We
        should specify how to treat such an error: do we ignore all but
        one of the choices, ignore all the choices, or declare an error?
        I tend to think of the processing of proposed or latent configs
        as a 2-step process: 1. process each configurations and build the
        equivalent "conventional" media block with m-line and attributes
        (no cap neg extensions); 2. choose a supportable media block to
        answer.  If the media block contains errors or conflicting
        parameters, resolve the conflict as SDP does now, reject it and
        pick another configuration, or refuse the offer.  That seems on
        the surface to make the least work for implementors of SDP, but
        I would appreciate any guidance in this regard.
>> parameters> reference the payload types of the redundant 
>> attribute? RFC 3407 (which you're hoping to obsolete) allows for any 
>> SDP attribute to be expressed as part of the latent configuration,
>>------------------------------------------------------------------------
>>

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 3 Feb 2008 15:16:22 +0200

Bob,

I do not think that negotiation of multiple media types in the same
medias stream is not suggested since mixing different media types (for
example audio and video) in the same stream is not recommended by RTP.

As for using two m-line with the same port number for alternative
configuration, this is not defined and was one of the motivation for
this work, for example for negotiation of different profiles (AVP and
SAVP). Use draft-ietf-mmusic-sdp-capability-negotiation 

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bob Gilman
Sent: Friday, February 01, 2008 8:57 AM
To: Guangwu He
Cc: [email-masked]
Subject: Re: [MMUSIC] SDP media capabilities question

Sammy-
My responses are embedded below.  The idea of negotiating multiple MIME
types for a single media stream may have some merit, as discussed below.
I'd like to hear from my coauthors and the mailing list about this and
the problems (or solutions) it might generate.
-Bob

Guangwu He wrote: 

  The offeror might send multiple proposed configurations, one
  with PCMU and DTMF events, one with G.729 and DTMF events,
  and one with iLBC and DTMF events.  

  According to this draft,offer is:

  a=mcap:1 audio PCMU G.729 iLBC DTMF

  m=audio 49170 RTP/AVP 97 98

  a=rtpmap:97 PCMU/8000

  a=rtpmap:98 DTMF/8000

  a=pcfg:1 m=1,4 pt=1:100 4:104

  a=pcfg:2 m=2,4 pt=2:101 4:104

  a=pcfg:3 m=3,4 pt=3:102 4:104

[rrg]: Yes.  Note that the configuration represented by the m= line is
the
       same as pcfg:1, except for payload types.  For completeness, we
should
       include at least one ecap attribute to set the encoding rate.

  according to RFC3264,offer is:

  m=audio 49170 RTP/AVP 97 98 99 

  a=rtpmap:97 PCMU/8000

  a=rtpmap:98 G.729/8000

  a=rtpmap:99 iLBC/8000

  m=audio 49170 RTP/AVP 100

  a=rtpmap:100 DTMF/8000

  They are equivalent.

[rrg]: I don't think this version is equivalent.  I can't find the
reference
       in RFC 3264 for using two media streams with the same transport
address.
       SDP (RFC 4566, section 5.14) states:
       "The semantics of multiple "m=" lines using the same transport
        address are undefined.  This implies that, unlike limited past
        practice, there is no implicit grouping defined by such means
and
        an explicit grouping framework ... should instead be used to
express
        the intended semantics."
       RFC 3264, section 8.3.3, does make a case for negotiating
multiple
       MIME types for a single media stream when the same information
may be
       encoded either of several ways.  The example given involves audio
       encoding of faxmodem signals and data encoding of fax content
(e.g.,
       T.38).  If I recall correctly, this problem has been treated in
the
       past by a number of techniques:
                 a. define an audio subtype for an encoding that's
really
                    equivalent to some other type/subtype, thereby
making
                    it easy to include in an m=audio line.
                 b. use the same port number to imply that multiple m=
lines
                    refer to the same stream.
                 c. use offer/answer to renegotiate the type/subtype for
an
                    existing stream.                 

  I know you example is correct,but from the draft,mcap define is:

  a=mcap:<med-cap-num> <subtype>*[ <subtype>],

  not you mention:

  a=mcap:<med-cap-num> <type> <subtype> *[<subtype>],

  and in this draft(p10) example is:a= mcap:2 H263-1998, H264.

  Are the draft ambiguous?

[rrg]: Not ambiguous, just wrong :-)  I left out the MIME types in
several
       examples.  I've corrected this in the upcoming version (-03).

  The draft say:we extend the framework by defining media capabilities 

  that can be used to negotiate media types and their associated 

  parameters.

  according the content of draft,the framework can not be used to 

  negotiate media types,but media subtypes.

[rrg]: Although I always assumed the MIME types within a media stream
       offer would be the same, I'm inclined to permit the use of
multiple
       types.

  thinks.

Sammy

 

Sammy-
1. The mcap attribute permits one to specify a proposed
   configuration that contains media subtypes that are
   different from the subtype(s) included in the configuration
   defined by the m= line.  For example, one might want to
   specify an m= line with PCMU audio (by default, the least
   preferred configuration), and a (preferred) configuration
   offering G.729 and DTMF events.  This is also useful to
   agree on a single audio encoding in one exchange: the
   offeror might send multiple proposed configurations, one
   with PCMU and DTMF events, one with G.729B and DTMF events,
   and one with iLBC and DTMF events.  The answerer can  then
   respond with the preferred configuration/codec (G.711 and
   DTMF events, say) in the answer m= line, along with a pair
   of latent configurations that indicate (future) support for
   G.729 and iLBC as well.
   Your example "a=mcap:1 audio video text" is not what we
   intended to define; the format is intended to permit one
   MIME type (e.g., audio, video, or text), and multiple
   subtypes belonging to that type.  From the draft:
       a=mcap:<med-cap-num> <type> <subtype> *[<subtype>]
   A typical mcap might look like:
       a=mcap:1 audio PCMU G729 iLBC
   which defines three media capabilities, audio/PCMU, audio/G729
   and audio/iLBC, numbered respectively as 1, 2, and 3.

2. The bcap attribute is intended to solve the problem
   discussed in section 3.10 of Flemming's SDPCapNeg
   draft, in the sense that a different maximum bandwidth
   can be specified for each configuration proposed within
   a media stream.  We haven't proposed a means to
   negotiate an overall session bandwidth limit.
Does this answer your questions?
-Bob
-------------------------------------------------------------
Bob Gilman    [email-masked] <mailto:[email-masked]>
303 898 9780 

??? wrote:
 
<>Hi,Reading the draft
(draft-ietf-mmusic-sdp-media-capabilities-02.txt),  I have the following
question:

1) I don't understand the a=mcap extension intent? Because media types
and media subtypes 

can provide by m= line, I guess intent of this extension is only
compress SDP packet? Additional, I have no ideal about "a=mcap:1 audio
image text" is correct or wrong.

2) The bandwidth 

negotiation(a=bcap) can not solve issue in
3.10("draft-ietf-mmusic-sdp-capability-negotiation-08.txt").

 
Regards
 
Sammy

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

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 3 Feb 2008 17:22:40 +0200

Bob,

Why do we need the payload types in the fcap I think that

    a=fcap:1 2/3

As Joe suggested will work while the pt should be in the pcfg

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bob Gilman
Sent: Saturday, February 02, 2008 7:09 AM
To: Joe Stone (joestone)
Cc: [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Joe-

   m=audio 12345 RTP/AVP 0

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 3 Feb 2008 17:25:50 +0200

Hi,

a=cpar:a=T38FaxVersion:0

should be based on the capability negotiation 

a=acap:1 T38FaxVersion:0

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Joe Stone (joestone)
Sent: Saturday, February 02, 2008 12:19 AM
To: [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Sun, 3 Feb 2008 08:34:52 -0800

Hi Roni,
 
That's correct. I picked a bad example. My question was intended to
address format-specific SDP attributes,

 I tried to sneak,
 
    a=cpar:a=gpmd:96 vbd=yes
 
into my example. Sorry for the confusion.
 
Joe

From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, February 03, 2008 9:26 AM
To: Joe Stone (joestone); [email-masked]
Subject: RE: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Hi,

a=cpar:a=T38FaxVersion:0

a=acap:1 T38FaxVersion:0

Roni

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 3 Feb 2008 18:46:05 +0200

Joe,

I am sorry, but where is gpmd specified

Roni Even

From: Joe Stone (joestone) [mailto:[email-masked]] 
Sent: Sunday, February 03, 2008 6:35 PM
To: Even, Roni; [email-masked]
Subject: RE: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Hi Roni,

 I tried to sneak,

    a=cpar:a=gpmd:96 vbd=yes

Joe

Hi,

a=cpar:a=T38FaxVersion:0

a=acap:1 T38FaxVersion:0

Roni

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Sun, 3 Feb 2008 08:48:48 -0800

ITU-T V.152.

From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, February 03, 2008 10:46 AM
To: Joe Stone (joestone); [email-masked]
Subject: RE: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Joe,

Roni Even

Hi Roni,

 I tried to sneak,

    a=cpar:a=gpmd:96 vbd=yes

Joe

Hi,

a=cpar:a=T38FaxVersion:0

a=acap:1 T38FaxVersion:0

Roni

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 3 Feb 2008 18:50:02 +0200

I asked about in the IETF as an SDP parameter

Roni

From: Joe Stone (joestone) [mailto:[email-masked]] 
Sent: Sunday, February 03, 2008 6:49 PM
To: Even, Roni; [email-masked]
Subject: RE: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

ITU-T V.152.

Joe,

Roni Even

Hi Roni,

 I tried to sneak,

    a=cpar:a=gpmd:96 vbd=yes

Joe

Hi,

a=cpar:a=T38FaxVersion:0

a=acap:1 T38FaxVersion:0

Roni

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Sun, 3 Feb 2008 10:23:00 -0800

As Bob points out, in order for this to work, the SDP processing layer
would need to know the format of the "a=fmtp" attribute associated with
the "RED" media format. RFC 2327/4566 defines the "a=fmtp" attribute in
such a way that the SDP processing layer doesn't need to understand the
format of the format-specific parameters.
 
This raises another question...
 
The "a=fcap" attribute is defined as,
 
        format-specific-parameter-list = <format-specfic-parameter>
        *[";"<format-specfic-parameter>] ; format-specific-parameter-
        list are defined per codec/capability.

How do you know that a semi-colon will serve to separate format specific
parameters in concatenating multiple "a=fcap" attributes? For example,
can't I define,
 
    a=mcap:1 audio telephone-event

    a=ecap:1 8000

    a=fcap:1 0-15

    a=fcap:1 66

    a=fcap:1 70

This would need to be concatenated as,

    a=fmtp:<format> 0-15, 66, 70

Wouldn't the SDP processing layer need to know that the format specific
parameters of the "a=fmtp" attribute associated with the
"telephone-event" media format are comma-separated as where other format
specific parameters may use other separators? Or do you restrict the use
of the concatenation feature to only those format specific parameters
which are separated by a semi-colon? You could argue that in the case of
"telephone-event" that "0-15, 66, 70" represents multiple values of a
single parameter (rather than multiple format specific parameters) and
therefore can't be split across multiple "a=fcap" lines. I'm just not
sure that there's a grammar which governs the character(s) used to
separate multiple format specific parameters.

By the way, here's another format-specific SDP attribute from RFC 4585,

      a=rtpmap:96 telephone-event/8000
      a=fmtp:96 0-16
      a=rtcp-fb:96 nack

I'm sure that there are others.

Joe

From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, February 03, 2008 9:23 AM
To: Bob Gilman; Joe Stone (joestone)
Cc: [email-masked]
Subject: RE: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Bob,

    a=fcap:1 2/3

Roni

Joe-

   m=audio 12345 RTP/AVP 0

Effectively, I'm after,

    a=fcap:1 PCMU/DVI4

    a=fcap:1 2/3

    a=cdsc:4 image udptl t38

    a=cpar:a=T38FaxVersion:0

Joe

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Feb 2008 09:37:01 +0000

> payload type appears in an fmtp attribute?

RFC 4588.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 4 Feb 2008 11:55:54 +0200

Colin thanks,

I think that is the future such drafts should try to use labels instead of actual PT, I think that it will make the attributes more generic

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: Monday, February 04, 2008 11:37 AM
To: Bob Gilman
Cc: [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

RFC 4588.

-- 

Colin Perkins

http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Feb 2008 10:45:40 +0000

How do you propose doing that? Using payload types has the great  
advantage of being simple.

Colin

On 4 Feb 2008, at 09:55, Even, Roni wrote:
> Colin thanks,
>
> I think that is the future such drafts should try to use labels  
> instead of actual PT, I think that it will make the attributes more  
> generic
>
> Roni
>
>
>
>
>

-- 
Colin Perkins
http://csperkins.org/

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 4 Feb 2008 14:24:43 +0200

Colin,

I meant that in the media capability we have a number for each media subtype declared in mcap. So you can use the number instead of the PT to define the relationship.

Roni

From: Colin Perkins [mailto:[email-masked]] 
Sent: Monday, February 04, 2008 12:46 PM
To: Even, Roni
Cc: Bob Gilman; [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

How do you propose doing that? Using payload types has the great advantage of being simple.

Colin

	Colin thanks,

	Roni

	RFC 4588.

	-- 

	Colin Perkins

	http://csperkins.org/

	 

	mmusic mailing list

	[email-masked]

 

-- 

Colin Perkins

http://csperkins.org/

---

From: Bob Gilman <[email-masked]>
Date: Mon, 04 Feb 2008 10:33:51 -0700

Thanks, Colin, but I think I asked the wrong question.  I should
have asked: do you know of another media-specific attribute of
the form a=<attr-name>:<payload-type> <parameter-list>?  The ones
that come to mind are rtpmap, fmtp, rtcp-fb, and the non-registered
gmap used in Joe Stone's example.  I suppose we could expect new
attributes in the future which apply to a specific format, but it
seems that parameters defining such attributes would normally be
placed in the fmtp attribute.  Joe Stone pointed out the rtcp-fb
attribute from RFC 4585 also.  I'm thinking this is enough to
encourage us to define a single capability attribute to cover these
cases.  I'm also thinking that contatenation is useful only when
the capability refers to the fmtp attribute.
Suggestions?
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

---

From: Bob Gilman <[email-masked]>
Date: Mon, 04 Feb 2008 10:49:46 -0700

Joe-
Indeed, I think we must consider the event set to be a single parameter.
After all, 0-15 is equivalent to 0,1,2,3,4,....  Another way to look at
this is: if the fmtp parameters for a particular format cannot be
concatenated via semicolon, then you must express them all in one
capability line.
One place I don't want to go is to define the concatenation method based
on the particular media subtype.
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

Joe Stone (joestone) wrote:
> Bob Gilman         [email-masked] <mailto:[email-masked]>        303 898 9780
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Mon, 4 Feb 2008 10:34:08 -0800

[js] Comments in line... 

-----Original Message-----
From: Bob Gilman [mailto:[email-masked]] 
Sent: Monday, February 04, 2008 11:34 AM
To: Colin Perkins
Cc: Joe Stone (joestone); [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Thanks, Colin, but I think I asked the wrong question.  I should have
asked: do you know of another media-specific attribute of the form
a=<attr-name>:<payload-type> <parameter-list>?  The ones that come to
mind are rtpmap, fmtp, rtcp-fb, and the non-registered gmap used in Joe
Stone's example.  I suppose we could expect new attributes in the future
which apply to a specific format, but it seems that parameters defining
such attributes would normally be placed in the fmtp attribute.

[js] One challenge in using the "a=fmtp" attribute is that "At most one
instance of this attribute is allowed for each (media) format." If in
the future, additional format-specific parameters are defined
corresponding to a media format for which the "a=fmtp" attribute is
already defined, you're forced to define a new format-specific
attribute. You can't extend the format-specific parameters associated
with an existing "a=fmtp" attribute even if the new parameters are
directly related.

Joe Stone pointed out the rtcp-fb attribute from RFC 4585 also.  I'm
thinking this is enough to encourage us to define a single capability
attribute to cover these cases.  I'm also thinking that contatenation is
useful only when the capability refers to the fmtp attribute.
Suggestions?
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

Colin Perkins wrote:
>> Good observation.  It looks like we overlooked the use of payload 
>> types in the fmtp attribute for redundancy.  Do you know of other 
>> cases in which a payload type appears in an fmtp attribute?
> 
> 
> RFC 4588.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>

---

From: Bob Gilman <[email-masked]>
Date: Mon, 04 Feb 2008 11:43:48 -0700

Roni-
The problem with using media capability numbers in the fcap attribute
is that we would have to know which parameters were media capability
numbers (to be replaced with payload types when forming an fmtp
attribute), and which were not.  As per RFC 4566, the parameters of
an fmtp attribute need not be understood by SDP.  This does mean that
the generator of capability attributes and potential or latent
configurations does have to be careful to match parameters that are
payload type numbers with pt= parameter(s) in the pcfg or lcfg lines.
To expand on your example:
	a=mcap:1 audio RED PCMU DVI4
	a=fcap:1 102/103
	a=pcfg:1 m=1,2,3 pt=1:100,2:102,3:103
would permit SDP to build an fmtp attribute like
	a=fmtp:100 102/103
without understanding what "102/103" means in the fcap line.
Admittedly, this doesn't permit one to use the same fcap line with
two different configurations and two sets of payload type numbers
for the primary and secondary encodings - but I don't think that's
necessary anyway for the redundancy case.  The encapsulating payload
type number can be used to distinguish two different configurations,
and in most cases, the format conbinations would likely be different
for different configurations anyway - e.g., one configuration with PCMU
and DVI4 redundancy, and another with PCMU and PCMU redundancy.
I admit it might mean work for the generator of the capability lines,
but, on the other hand, if the caps are generated from "conventional"
SDP lines, the work is easy because the fcap parameters need not be
understood.
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

---

From: Bob Gilman <[email-masked]>
Date: Mon, 04 Feb 2008 12:16:56 -0700

Joe-
Indeed, it's a challenge that only one fmtp attribute is permitted
per media format - that's why we suggested concatenation for those
cases with numerous combinations of parameters - but I don't
understand your comment about adding parameters.  SDP doesn't care
(or need to know) if a new parameter is defined for a format - it's
up to the media processing layer to interpret it, ignore it, or
reject it.   For example, RFC 4876 added the Mode-Change-Capability
to the AMR and AMR-WB media formats of RFC3267 (which it obsoletes).
This doesn't change SDP processing at all.  What am I missing?
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Mon, 4 Feb 2008 12:25:23 -0800

Hi Bob,

Yes, it's a function of the "media tool" that sits on top of the SDP
processing layer and whether changes/additions to the format-specific
parameters would be backwards compatible. In your example, is a "media
tool" based on RFC 3267 expected to ignore or reject an "a=fmtp"
attribute with the Mode-Change-Capability parameter? Does RFC 3267 state
whether unrecognized parameters should be ignored? Rejected?

Here's another example...

RFC 2198 defines the "a=fmtp" attribute in conjunction with the "RED"
media format as,

	a=fmtp:<format> <primary encoding>/<secondary
encoding>/<tertiary encoding>/...

For example,

There was a proposal to extend the format-specific parameters to allow
for a preferential list of redundancy formats. For example,

	m=audio 3456 RTP/AVP 18 96 97
	a=rtpmap:96 RED/8000
	a=fmtp:96 97/97/97; 97/97
      a=rtpmap:97 PCMU/8000

This offer would reflect a preference for two-levels of redundancy over
one-level of redundancy. It was concluded that the "a=fmtp" attribute
could not be extended in this way while still expecting backward
compatibility with existing RFC 2198 based implementations. 

We're probably a little off track at this point. We know that there are
format-specific attributes other than "a=rtpmap" and "a=fmtp". We're
discussing whether there will be one, two, 10 or 100 new format-specific
attributes over the coming years. I'm not sure that it matters. We need
a general approach to accommodating new (and existing) format-specific
attributes.

Joe

-----Original Message-----
From: Bob Gilman [mailto:[email-masked]] 
Sent: Monday, February 04, 2008 1:17 PM
To: Joe Stone (joestone)
Cc: Colin Perkins; [email-masked]
Subject: Re: [MMUSIC] SDP Media Capabilities Negotiation a=fcap

Joe-
Indeed, it's a challenge that only one fmtp attribute is permitted per
media format - that's why we suggested concatenation for those cases
with numerous combinations of parameters - but I don't understand your
comment about adding parameters.  SDP doesn't care (or need to know) if
a new parameter is defined for a format - it's up to the media
processing layer to interpret it, ignore it, or
reject it.   For example, RFC 4876 added the Mode-Change-Capability
to the AMR and AMR-WB media formats of RFC3267 (which it obsoletes).
This doesn't change SDP processing at all.  What am I missing?
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

Joe Stone (joestone) wrote:
> mind are rtpmap, fmtp, rtcp-fb, and the non-registered gmap used in 
> Joe Stone's example.  I suppose we could expect new attributes in the 
> future which apply to a specific format, but it seems that parameters 
> defining such attributes would normally be placed in the fmtp
attribute.
> 
> [js] One challenge in using the "a=fmtp" attribute is that "At most 
> one instance of this attribute is allowed for each (media) format." If

> in the future, additional format-specific parameters are defined 
> attribute to cover these cases.  I'm also thinking that contatenation 
> is useful only when the capability refers to the fmtp attribute.
> Suggestions?
> -Bob

---

From: Bob Gilman <[email-masked]>
Date: Mon, 04 Feb 2008 14:36:59 -0700

Joe-
Using your example for optional redundancy encodings, I think
the problem with existing "media tool" limitations is better
solved via extending the fmtp parameters and capabilities
negotiation, rather than by adding a new attribute to SDP.  The
latter solution requires SDP to recognize the new attribute and
to know that its parameters must be passed to the media tool,
and it fails if a "new" SDP is feeding an old media toolk (or
vice versa).  To use your example, we could offer
	m=audio 54321 RTP/AVP 0 96 97
	a=rtpmap:96 RED/8000
	a=rtpmap:97 RED/8000
	a=rtpmap:0 PCMU/8000
	a=fmtp:96 0/0/0
	a=fmtp:97 0/0
If I recall correctly, Colin Perkins stated that a sender could
provide any level of redundancy (at least up to the level of
0/0/0) even if the lines with pt=97 were not present.
We could rewrite the offer with capabilities as:
	m=audio 54321 RTP/AVP 0
	a=mcap:1 PCMU RED RED
	a=ecap:1,2,3 8000
	a=fcap:2 0/0
	a=fcap:3 0/0/0
	pcfg:1 m=2,1 pt=2:96,1:0
	pcfg:2 m=3,1 pt=2:97,1:0
This would work with an old media tool, I think, but it brings
up another question:
When offered a number of configurations, should SDP pick one,
verify it with the media tool then format its reply?  If the
verification fails, SDP can move on to the next preferred
configuration, and try again, I suppose.
Also, shouldn't media tools be written with the expectation that
new media-specific parameters might be added later?  Should
SDP specify how unrecognized parameters and/or unsupportable
values should be treated when passed to the media tool?
All we can do is take what we're given and pass it up - if the
media tool can't understand it, then at least we tried.
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780