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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 27 July 2007 00:58 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 1IEEA7-0002BD-0B; Thu, 26 Jul 2007 20:58:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEEA5-0002B7-Sd for avt@ietf.org; Thu, 26 Jul 2007 20:58:33 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEEA4-000569-EJ for avt@ietf.org; Thu, 26 Jul 2007 20:58:33 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C48A22058A; Fri, 27 Jul 2007 02:58:31 +0200 (CEST)
X-AuditID: c1b4fb3c-aee7cbb0000007e1-38-46a943370523
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CBA02045F; Fri, 27 Jul 2007 02:58:31 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 02:58:31 +0200
Received: from [138.85.15.32] ([138.85.15.32]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 02:58:30 +0200
Message-ID: <46A94335.1090104@ericsson.com>
Date: Fri, 27 Jul 2007 02:58:29 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: "Even, Roni" <roni.even@polycom.co.il>
References: <144ED8561CE90C41A3E5908EDECE315C04C236A6@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04C236A6@IsrExch01.israel.polycom.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jul 2007 00:58:30.0766 (UTC) FILETIME=[3FC6A0E0:01C7CFE9]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
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

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