[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