Subject: Re: [AVT] WGLC on draft-ietf-avt-rtp-g719-00

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Sep 2008 17:44:57 +0100

On 23 Aug 2008, at 22:37, Roni Even wrote:
> At the Dublin meeting it was agreed to start a WGLC on http:// 
> tools.ietf.org/html/draft-ietf-avt-rtp-g719-00.
>
> This is the RTP payload specification for G.719 a new  ITU-T codec.
>
> We will start a 2 weeks working group last call.
>
> Please review the draft and send comments till September 8th
>

Just one comment: the CBR parameter has an impact on congestion  
control. This should be discussed in section 9.

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Sep 2008 14:59:09 +0200

Roni Even skrev:
> Hi,
> 
> At the Dublin meeting it was agreed to start a WGLC on 
> http://tools.ietf.org/html/draft-ietf-avt-rtp-g719-00.
> 
> Please review the draft and send comments till September 8^th
> 

Hi,

We have made a re-review ourselves and found a few small issues that 
needs to be addressed plus a few editorials

1. It is not particular clear how on can use  NO_DATA if sending 
redundant frames to create sparse protection. Intends to clarify that it 
is allowed.

2. Due to some missfortunate wording the channel order is dependent on 
the signalling used to setup things. Will change to indicate that the 
channel order in AVP is the one that will be used for the different 
number of channels.

3. The parameter Int-delay and the value of the interleaving parameter 
when being used in offer/answer seems to be wrongly defined.

    interleaving:  Indicates that interleaved mode SHALL be used for the
       payload.  The parameter specifies the number of frame-block slots
       available in a de-interleaving buffer (including the frame that is
       ready to be consumed).  Its value is equal to one plus the maximum
       number of frames that can precede any frame in transmission order
       and follow the frame in RTP timestamp order.  The value MUST be
       greater than zero.  If this parameter is not present, interleaved
       mode SHALL NOT be used.

    int-delay:  The minimal media time delay in RTP timestamp ticks that
       is needed in the de-interleaving buffer, i.e., the difference in
       RTP timestamp ticks between the earliest and latest audio frame
       present in the de-interleaving buffer.

 From Offer/answer:

    o  The "int-delay" parameter is declarative.  For streams declared as
       sendrecv or recvonly, the value indicates the maximum initial
       delay the receiver will accept in the de-interleaving buffer.  For
       sendonly streams, the value is the amount of media time the sender
       intends to use.  The value SHOULD be copied into any response.

 From Interleaving text:
                       An SDP answerer MUST include, in the SDP answer
       for a payload type, the following parameters unmodified from the
       SDP offer (unless it removes the payload type): "interleaving";
       and "channels".  However, the value of the Interleaving parameter
       MAY be changed.

So the problem is that the relation ship between the two parameters are 
not well described. This affects how they can be used and what they mean 
for different directionalties etc. So we will need to make some changes 
here before requesting publication.

The outline of a solution to this last issue is the following:

A agent used the value in Interleaving to declare the size of the buffer 
it has to receive packets in. The stream sender uses int-delay to 
declare what initial delay a receiver needs to wait to avoid issues with 
buffer-underrun due to the interleaving. Thus the relationship is that 
int-delay can't be larger than the full size of the buffer declared by 
the receiver. Thus if a offerer thinks it will have more space that 
actually available then it automatically trim this parameter to the 
equal of interleaving*20ms (frame size).

When it comes to directionality the meaning of Interlaving will be:

sendonly: Suggestion for size of interleaving buffer for peer
recvonly: Actual size of buffer
sendrecv: Actual size of buffer

And for the Int-delay parmater:
sendonly: Actual delay to wait unless capped
recvonly: Suggested value (recommened to not send)
sendrecv: Actual delay to wait unless capped

To deal with multiple sources, the values in INT-delay should be 
expressed on a per SSRC basis.

For multicast changing the receiver buffering requirement is forbidden. 
Accept or refuse session. Int-delay can still be expressed for SSRC that 
the agent is going to send.

Comments, or we will publish an update in a few days.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt