Subject: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG item

From: "Roni Even" <[email-masked]>
Date: Sun, 24 Aug 2008 00:32:25 +0300

Hi,

During the Dublin meeting it was agreed to ask if
http://tools.ietf.org/id/draft-lakaniemi-avt-rtp-evbr-02.txt can become a WG
items.

This is the RTP payload specification for G.718 that is in final approval at
the ITU. Payload specifications for standard codec are within the charter of
the WG.

If there are no objections by the September 1st we will accept it as a WG
item and add this draft to the charter of AVT

Roni Even

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 31 Aug 2008 23:36:18 +0100

Hi,

On 23 Aug 2008, at 22:32, Roni Even wrote:
> During the Dublin meeting it was agreed to ask if http:// 
> tools.ietf.org/id/draft-lakaniemi-avt-rtp-evbr-02.txt can become a  
> WG items.
>
> This is the RTP payload specification for G.718 that is in final  
> approval at the ITU. Payload specifications for standard codec are  
> within the charter of the WG.
>
> If there are no objections by the September 1st we will accept it  
> as a WG item and add this draft to the charter of AVT
>

I have no objection in principle to taking this draft as a work item,  
but I think there are a couple of problems with the current draft:

- Section 3.6 introduces a new cross-stream/cross-layer  
synchronisation mechanism, as an alternative to RTCP SR information.  
Such a thing might be appropriate - we talked about the need for this  
for SVC in Dublin - but it should be a general mechanism, rather than  
something specific to a payload format. I think Jonathan Lennox was  
going to write a draft on this subject?

- As noted in Section 4, an RTCP APP packet isn't appropriate for  
sending configuration data. This should likely be a new RTCP AVPF  
feedback packet.

I would suggest that these be addressed before the draft is accepted  
as a work item, since there seemed to be consensus on both directions  
in Dublin.

Also, a more minor issue is that Section 3.3 should reference RFC  
5117, and explain that such devices are RTP translators, and so must  
follow RFC 3550, section 7.

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