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

"Even, Roni" <roni.even@polycom.co.il> Wed, 25 July 2007 17:35 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 1IDklk-00083r-Lh; Wed, 25 Jul 2007 13:35:28 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkli-00083E-Sc for avt@ietf.org; Wed, 25 Jul 2007 13:35:26 -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 1IDklh-0003d7-H2 for avt@ietf.org; Wed, 25 Jul 2007 13:35:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 25 Jul 2007 20:36:20 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C04C236A6@IsrExch01.israel.polycom.com>
In-Reply-To: <46A785A7.70100@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review draft-ietf-avt-avpf-ccm-07
Thread-Index: AcfO352dk45OybTnQqeS9Kd4iKYBPQAAUrsA
From: "Even, Roni" <roni.even@polycom.co.il>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742
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>
Content-Type: multipart/mixed; boundary="===============1867130468=="
Errors-To: avt-bounces@ietf.org

Thanks,

Inline

 

> > 2. In 4.2.1.2 " If the media sender concludes that it can increase the

> maximum total media bit rate value, it SHALL wait before actually doing

> so, for a period long enough to allow a media receiver to respond to the

> TMMBN if it determines that its tuple belongs in the bounding set."

> >

> > I was wondering if the SHALL is also true for unicast point to point

> case.

> >

> 

> Yes, this also applies to point to point. The reason is that one can't

> really reliably know which topology you are in. Thus, it is safest to do

> this also in point to point cases. Do you think we need to add any text

> on this?

> 

[RE:] I think a clarification will make sense. 

> >

> >

> >

> >

> > 6. In the 7.2 " The offerer MAY indicate the capability to support

> selected codec commands and indications.  The answerer MUST remove all ccm

> parameters which it does not understand or does not wish to use in this

> particular media session."

> > I am not sure what you mean do not want to use, is it does not want to

> send or just does not want to receive but may send.

> > Based on your response the text for the answer in example 3 should have

> the same semantics.

> >

> >

> 

> The intention is that you must have the capability to receive such CCM

> requests and in cases, like TSTR to send the response. A agent is not

> required to initiate CCM messages, but expected I would say. Thus I

> propose the following addition to section 7.2:

> 

> 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.

> 

[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.

 

 

 

 

 

> 

> 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