[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained Control ofRequired Extensions
Fleming,
thanks for reminding me that unknown or unsupported potential
configuration parameter extensions are ignored.
I think we should keep this property as it is currently specified.
That's probably easier to implement and its more inline with current SDP
rules in general.
I would rather go with your proposal of a pcfg parameter r=foo, that
must be supported in the core.
I didn't get your point about a separate prefix in "-f=1,[2]". Was it
just meant as alternative to r=foo?
Regards
Thomas
________________________________
From: Flemming Andreasen [mailto:fandreas at cisco.com]
Sent: Wednesday, September 12, 2007 2:45 PM
To: Stach, Thomas
Cc: mmusic
Subject: Re: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained
Control ofRequired Extensions
Stach, Thomas wrote:
Fleming,
I agree.
We should not unnecesarily restrict the extensibility.
I just want to clarify what you have in mind.
The declaration of optional and mandatory attributes
from draft 06 looks
as follows:
a=pcfg:1 a=1,2,[3,4]
Here attribute 1 and 2 are mandatory to support and
[3,4] are optional.
If there is an extension foo that defines a letter f for
the pcfg
attribute.
A a=creq:foo at media level would mean that the
extension must be
supported for the m-line
and all related pcfg for this m-line.
Right.
If just a potential configuration is affected the pcfg
attribute one
could extend the "bracket syntax" to the extensions.
That could look like
a=pcfg:1 a=1,2,[3,4] f=1,2 in case of mandatory support
for 1,2 and
a=pcfg:1 a=1,2,[3,4] [f=1,2] in case of optional support
for 1,2 and
a=pcfg:1 a=1,2,[3,4] f=1,[2] in case of mandatory
support for f=1 and
optionallly f=2.
Is this (or something similar) what you have in mind?
The current rules say that unknown or unsupported potential
configuration parameter extensions are ignored, and hence I was thinking
more along the lines of listing the required option tags as part of the
pcfg line, e.g.
a=pcfg:1 a=1,2,[3,4] f=1,2 r=foo, in case of mandatory support
for 1,2 and
a=pcfg:1 a=1,2,[3,4] f=1,2 in case of optional support for 1,2
and
a=pcfg:1 a=1,2,[3,4] f=1,[2] r=foo in case of mandatory support
for f=1 and optionallly f=2.
Your proposal works equally well though, if not better since
it's a more compact representation. It requires a few minor changes to
the current rules and syntax, but that could certainly be done (we might
consider just using a separate prefix on the parameter, e.g. "-f=1,[2]"
while we are at it to cover all possible combinations of required
extension support).
If yes, then such an extended "bracket syntax" should be
specified
already in the core.
It's only specified for the attribute capability list values,
not the extension capability list (or list values), so we still need to
make a few tweaks.
Thanks
-- Flemming
Regards
Thomas
-----Original Message-----
From: Flemming Andreasen
[mailto:fandreas at cisco.com]
Sent: Tuesday, September 11, 2007 11:32 PM
To: mmusic
Subject: [MMUSIC] SDPCapNeg-06 Issue #3: More
Fine-grained
Control ofRequired Extensions
The core SDP Capability Negotiation Framework
includes support for
extensions. Unknown extensions are by default
ignored, however
extensions can have an option tag associated
with them, and
support for
those can be required. The way this is done
currently is by
including a
single "a=creq" at the session-level and/or
media-level(s), which
indicate the option tags that MUST be supported
in order to
process the
SDP Capability Negotiation extensions. When
provided at the
session-level, the extensions must be supported
throughout the entire
SDP, and when provided at the media-level, the
extensions must be
supported for that particular media description
("m=" line).
As part of the media capabilities discussion,
Magnus expressed some
concerns about forward compatibility and not
having enough
flexibility
for later (if media capabilities are not
included in the core, which
they are not). Proper extensibility support is
key to address
this IMO,
and the question here is whether the current
extension mechanism is
flexible enough.
The design team had originally discussed
"required" option tags being
supported not only at the session and media
level (as is done
currently), but to also support them at the
individiaul potential
configuration level. This way, rather than
requiring support for a
particular extension throughout the entire SDP
or in a
particular media
description in order to even use the SDP
capability negotation
framework, we can simply skip individual
potential configuration
attributes where the necessary extensions are
not supported.
At the time, it was felt that we could get by
without such
functionality, however I'd like to reconsider
that here. The basic
question is whether there ever is a need to
require support for a
particular extension in one potential
configuration, but not
another one
in the same media description. I believe the
answer to that
is yes once
we start considering combinations of
capabilities. Consider the
following example:
a) If the transport protocol is AVPF, and media
capabilities are
supported, then use H.264 with the RFC 4588 RTP
retransmission payload
format. The RTP retransmission uses
session-multiplexing and we have
another extension in place to indicate an
inter-media stream
synchronization dependency. This extension must
be supported as well.
b) If the transport protocol is regular AVP, and
media
capabilities are
supported then use H.264 with FEC (RFC 2198 and
draft-ietf-avt-ulp-23.txt)
The two alternatives above each correspond to a
potential
configuration
which uses transport protocol capabilities
(core) and media
capabilities
(extension), however the first one requires
support for an additional
capability (which the second does not). Thus,
indicating required
capabilities at the media-level alone does not
produce the desired
result (consider the case where the answerer
supports only the media
capabilities).
While the use cases for this functionality may
not be that
common, they
are nevertheless there, and will be important to
some. I believe the
functionality is important to have, it doesn't
add much additional
complexity, and if we are to have it, it needs
to be in the
core. Based
on this, I'd like to suggest we add this
functionality in the core.
Please let me know if you agree or disagree with
this.
Thanks
-- Flemming
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic