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

"Even, Roni" <roni.even@polycom.co.il> Mon, 30 July 2007 09:51 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRup-0000cs-Fj; Mon, 30 Jul 2007 05:51:51 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRun-0000Xt-FH for avt@ietf.org; Mon, 30 Jul 2007 05:51:49 -0400
Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFRum-0006l0-9O for avt@ietf.org; Mon, 30 Jul 2007 05:51:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 30 Jul 2007 12:52:48 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C04CB2B00@IsrExch01.israel.polycom.com>
In-Reply-To: <46A94335.1090104@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review draft-ietf-avt-avpf-ccm-07
Thread-Index: AcfP6Y4Qx9TZN6+aREav2tgwpZLd2ACpcz2g
From: "Even, Roni" <roni.even@polycom.co.il>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: bo.burman@ericsson.com, stewe@stewe.org, avt@ietf.org
Subject: [AVT] RE: Review draft-ietf-avt-avpf-ccm-07
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Magnus,
Looks OK.
Thanks
Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Friday, July 27, 2007 3:58 AM
> To: Even, Roni
> Cc: avt@ietf.org; stewe@stewe.org; bo.burman@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@ericsson.com
> ----------------------------------------------------------------------

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