[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