[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Review draft-ietf-avt-avpf-ccm-07
Thanks for the review.
Even, Roni skrev:
Hi
It took me some time but I have some comments and nits
1. In section 3.5.2 I suggest to delete "(as it is common in state-of-the-art video conferencing systems). I am not sure that it adds value and voice an opinion.
Agreed
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?
3. In 4.2.2.2
"As indicated in section 4.2.1.2, when a media sender determines
that an "owner" of a bounding tuple has left the session, then
that tuple is removed from the bounding set, and the media sender
SHALL send a TMMBN message indicating the remaining bounding
tuples. If there are no remaining bounding tuples a TMMBN without
any FCI SHALL be sent to indicate this."
If there are no remaining bounding set what is the current bit rate. Does it mean that the sender may raise the bit rate to the negotiated rate in the signaling.
Yes, we have clarified this by adding the following sentence:
"Without a remaining bounding tuple, the maximum media bit rate and
maximum packet rate negotiated in session signaling, if any, apply."
4. In 4.3.1.2
Do we need the note bellow in the final version.
"Note: Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application viewpoint, but is problematic from a congestion control point of view. "As soon as possible" as mentioned above appears to be a reasonable compromise"
No, but this has been moved into Section 4.3.2.5 (Remarks) where it
makes more sense to have it as explanation.
5. in section 7.1 " MaxPacketRateValue = 1*15DIGIT" what are the units for this parameter. I think that based on the example it is in 1000's of bits per second but please clarify.
Fix the value in example 3 based on the units, currently it say 120 and I assumed 120*1000 bits/s
We added clarification that this is packets per second.
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.
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