[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] review of additional offer/answer text in draft-ietf-mmusic-decoding-dependency
Dear all,
during the IESG evaluation of draft-ietf-mmusic-decoding-dependency,
there was a request for additional text describing the negotiation of
the dependencies between offerer and answerer. We tentatively added the
following text to section "6.1. Usage with the SDP Offer/Answer Model"
based on a proposal by Magnus:
"If the answerer understands the DDP semantics, it is necessary to take
the "depend" attribute into consideration in the offer/answer procedure.
The main rule for the “depend” attribute is that the offerer decides the
number of media streams and the dependency between them. The answerer
cannot change the dependency relations.
For unicast sessions where the answerer receives media, i.e. for offers
including media streams that have a directionality indicated by
“sendonly”, “sendrecv” or have no directionality indicated, the answerer
MAY remove the media's operation points. The answerer MUST use the
dependency relations provided in the offer when sending media. The
answerer MAY send according to all of the operation points present in
the offer, even if the answerer removes some of those operation points.
Thus an answerer can limit the number of operation points being
delivered to the answerer while the answerer can still send media to the
offerer using all of the operation points indicated in the offer.
For an offer using multicast, the answerer MUST accept all media streams
and their related decoding dependencies or remove non-accepted media
streams completely. Due to the nature of multicast, the receiver can
select which operation points, it actually receives and processes. For
multicast sessions that allow the answerer to also send data, the
answerer MAY send all of the offered operations points.
In any case, if the answerer cannot accept one or more offered operation
points and/or the media stream's dependencies, the answerer MAY
re-invite with an offer including acceptable operation points and/or
dependencies.
Note: Applications may limit the possibilities to perform a re-invite.
The previous offer is also a good hint to the capabilities of the other
agent."
Any comments? Otherwise we will integrate the proposed text and proceed.
Thanks,
Thomas
--
Thomas Schierl
--------------
Fraunhofer HHI
----
Visit us at
OFC 2009 / March 24-26 / San Diego, California / Hall B1, Booth 411
http://www.ofcnfoec.org/
Web 2.0 Expo / March 31 - April 03 / San Francisco, California / Booth 415
http://www.web2expo.com/webexsf2009