[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] RE: Review draft-ietf-avt-avpf-ccm-07



Magnus,
Looks OK.
Thanks
Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com]
> Sent: Friday, July 27, 2007 3:58 AM
> To: Even, Roni
> Cc: avt at ietf.org; stewe at stewe.org; bo.burman at ericsson.com
> Subject: Re: Review draft-ietf-avt-avpf-ccm-07
> 
> Hi Roni,
> 
> Please see inline.
> 
> Even, Roni skrev:
> >>  > 2. In 4.2.1.2 " If the media sender concludes that it can increase
> the
> >
> > */ [RE:] I think a clarification will make sense. /*
> >
> 
> Okay, I will include the following:
> 
> This should be done also for point-to-point sessions, as it not
> guaranteed that a participant can determine correctly if the sources are
> present in a single node and co-ordinated.
> 
> 
> Is that okay? I only use should as it is strictly not needed if you are
> convinced that you can correctly determine that the back-off is not
> needed.
> 
> 
> 
> >>
> >
> > */ [RE:] I am still not sure I understand. Example the offer includes
> > tmmbr, tstr and fir. The answer responds with tstr only. /*
> >
> > */ Does it mean that the answerer may send tmmbr, tstr and fir but the
> > offerer can only send tstr. /*
> >
> > */ Also if the above is right it will mean the answerer sending tmmbr
> > will be able to process the response. /*
> >
> 
> Okay, I think there might be missing some word in there that these are
> symmetric and both side need to announce support for it to be possible
> to use it. These parameter does not make sense as declarative ones.
> 
> Now the complete sectiond reads:
> 
> 7.2. Offer-Answer
> 
> The Offer/Answer [RFC3264] implications for codec control protocol
> feedback messages are similar to those described in [RFC4585].  The
> offerer MAY indicate the capability to support selected codec commands
> and indications.  The answerer MUST remove all ccm parameters
> corresponding to the CCM messages that it does not support or does not
> desire to be used in this particular media session.  The answerer MUST
> NOT add new ccm parameters in addition to what has been offered.  The
> answer is binding for the media session and both offerer and answerer
> MUST only use feedback messages that both sides have explicitely
> indicated in the messages.  In others words only the joint subset of CCM
> parameters from the offer and answer may be used.
> 
> Note, that including a CCM parameter in an offer or answer indicates
> that the agent (offerer or answerer) is at least capable of receiving
> the corresponding CCM message(s) and act upon them. In cases when the
> reception of a negotiated CCM messages mandates the agent to respond
> with another CCM message, it also must have that capability. Although
> not mandated to initiate CCM messages of any negotiated type it is
> generally expected that the agent will initiate CCM messages when
> suitable.
> 
> The session maximum packet rate parameter part of the TMMBR indication
> is declarative and everyone SHALL use the highest value indicated in a
> response.  If the session maximum packet rate parameter is not present
> in an offer it SHALL NOT be included by the answerer.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt