Subject: [MMUSIC] review of additional offer/answer text in draft-ietf-mmusic-decoding-dependency

From: Thomas Schierl <[email-masked]>
Date: Wed, 18 Mar 2009 11:19:23 +0100

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