Subject: [AVT] draft-gmassey-avt-rtp-aptx-01.txt

From: "Greg Massey" <[email-masked]>
Date: Wed, 16 Apr 2008 10:08:53 +0100

Dear Chairman and members,

could I ask that you formally adopt the draft rfc (see link below) as
part of an AVT draft. 

http://www.ietf.org/mail-archive/web/i-d-announce/current/msg19892.html 

Many Thanks

Gregory Massey

Chief Technical Officer 

Tel: +442890677200

Mob: +447841102975

Email: [email-masked]

URL: www.aptx.com

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 21 Apr 2008 22:41:07 +0100

Greg,

RTP payload formats fit within our charter, so there are no  
procedural issues with adopting this as an AVT working group draft.  
Doing so will assign change control to the working group, with the  
possibility that the group will require changes be made to the draft.  
Note also that any IPR associated with this draft must be declared,  
following IETF rules (https://datatracker.ietf.org/ipr/about/).

If this is acceptable, we will issue the required call for objections  
before the draft can be adopted.

Speaking as an individual, rather than working group chair, I had two  
areas of concern from my initial review of the draft. Firstly, the  
draft notes:

                The apt-X and enhanced apt-X algorithms can carry an
    ancillary data stream and synchronisation information within the
    compressed audio stream without additional overhead.  The ancillary
    data stream can be used to transport data or timecode data for
    synchronisation with video.

It's generally not desirable to include information within the  
payload that's redundant with the RTP headers, and I wonder if the  
ancillary data can be elided for RTP transmission (following the  
guidelines in RFC 2736)?

Secondly, it is not obvious how to relate the format parameter "audio- 
mode" to the standard SDP channels specifier. That's not necessarily  
a problem, but may require discussion.

Colin

On 16 Apr 2008, at 10:08, Greg Massey wrote:
> could I ask that you formally adopt the draft rfc (see link below)  
> as part of an AVT draft.
>
>
>

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

---

From: "Greg Massey" <[email-masked]>
Date: Mon, 21 Apr 2008 22:45:10 +0100

Hi Colin,

many thanks for getting back and the terms are indeed fine for APT. In
terms of the ancillary data this feature is something that can be
dropped

as it is a function of the algorithm not the payload. The payload format
will not be affected by the inclusion/exclusion of this paragraph. I
will review

your second point tomorrow and get back to you. In terms of IPR would
this have to included details of the algorithm itself, or is it
acceptable that

anyone using the draft would usually be a licensee of the algorithm?

Regards

Greg

From: Colin Perkins [mailto:[email-masked]] 
Sent: 21 April 2008 22:41
To: Greg Massey
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVT] draft-gmassey-avt-rtp-aptx-01.txt

Greg,

RTP payload formats fit within our charter, so there are no procedural
issues with adopting this as an AVT working group draft. Doing so will
assign change control to the working group, with the possibility that
the group will require changes be made to the draft. Note also that any
IPR associated with this draft must be declared, following IETF rules
(https://datatracker.ietf.org/ipr/about/).

Speaking as an individual, rather than working group chair, I had two
areas of concern from my initial review of the draft. Firstly, the draft
notes:

It's generally not desirable to include information within the payload
that's redundant with the RTP headers, and I wonder if the ancillary
data can be elided for RTP transmission (following the guidelines in RFC
2736)? 

Secondly, it is not obvious how to relate the format parameter
"audio-mode" to the standard SDP channels specifier. That's not
necessarily a problem, but may require discussion.

Colin

	could I ask that you formally adopt the draft rfc (see link
below) as part of an AVT draft. 

	Many Thanks

	Gregory Massey

	Chief Technical Officer

-- 

Colin Perkins

http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Apr 2008 21:50:15 +0100

Greg,

On 21 Apr 2008, at 22:45, Greg Massey wrote:
> many thanks for getting back and the terms are indeed fine for APT.
>

Okay, thanks.

> In terms of the ancillary data this feature is something that can  
> be dropped as it is a function of the algorithm not the payload.  
> The payload format will not be affected by the inclusion/exclusion  
> of this paragraph. I will review your second point tomorrow and get  
> back to you.
>

Does it make sense to mandate that ancillary data MUST NOT be used  
for synchronisation when apt-X is carried over RTP, with applications  
using the standard RTP mechanisms instead?

> In terms of IPR would this have to included details of the  
> algorithm itself, or is it acceptable that anyone using the draft  
> would usually be a licensee of the algorithm?
>

We're concerned about IPR on the RTP payload format draft, rather  
than IPR on the codec itself.

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

---

From: "Greg Massey" <[email-masked]>
Date: Wed, 23 Apr 2008 11:23:05 +0100

Hi Colin,

See inline

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 22 April 2008 21:50
To: Greg Massey
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVT] draft-gmassey-avt-rtp-aptx-01.txt

Greg,

>using the standard RTP mechanisms instead?

It does not matter to the codec if it is enabled or not as the codec
will carry
on decoding irrespective.

>than IPR on the codec itself.

There is no IPR in the payload format that I am aware of.

Thanks

Greg

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