Re: [payload] draft-rea-payload-rtp-aptx-01

["Derrick Rea" <[e-mail]>]

Thanks for the comments. I've grouped the answers together into this post.

Derrick

__________________________________________________________________________________________________________________________________

Answer to Ross Finlayson, Sent: 03 February 2012 01:46, Subject: Re: [payload] draft-rea-payload-rtp-aptx-01

 

>> IMHO, the "aux=out-of-bound-aux" and "aux-port: <port-number>" mechanism - for specifying a separate port number on which an 

>> "auxiliary data stream" should be sent - needs closer scrutiny.  I don't know of another RTP payload format that uses a separate port 

>> number that's specified in a SDP "a=" parameter line, rather than on the "m=" line.

 

>> This raises lots of questions - for example, do packets on the "auxiliary data stream" share the same RTP sequence number and 

>> timestamp space as the 'main stream'?  And what about RTCP?

 

>> Does anyone actually implement sending the "auxiliary data stream" on a separate port number?  If not, then perhaps this feature should 

>> be removed from the specification...

 

Ross,

 

I now see that defining the "aux=out-of-bound-aux" and "aux-port: <port-number>" mechanism as a media type attribute is not correct. Definitely makes more sense to define any out of band aux stream in the session using the current media type definitions i.e. "m=text","m=application", or "m=message". I will update this in the next version of the draft. Thanks Ross!

__________________________________________________________________________________________________________________________________

Answer to Kari Mäenpää, Sent: 02 February 2012 12:02, Subject: Re: [payload] draft-rea-payload-rtp-aptx-01

Thanks kari, I will fix this in the next version of the draft.

__________________________________________________________________________________________________________________________________

Answer to Michel Quaix, Sent: 02 February 2012 12:02, Subject: Re: [payload] draft-rea-payload-rtp-aptx-01

Thanks Michael, I will fix these mistakes in the next version of the draft.

________________________________________________________________________________________________________________________________

 

Answer to Hans-Heinrich Hansen, Sent: 01 February 2012 12:02, Subject: Re: [payload] draft-rea-payload-rtp-aptx-01

 

>> I think that two types of Standard apt-X modes are available: "with sync"and "without sync". How these modes will be signalled or could one type ignored?

Answer - Yes, Standard apt-X and E apt-X do have "with sync"and "without sync" configurations. I've also not included the ability to embedded auxilliary data into the left, right or both configuration that Standard apt-X allows. I propose adding  

1) A media type attribute embedded-sync = off/on that applies to both variants of apt-X 

2) Media type attributes embedded-aux-left=off/on and embedded-aux-right=off/on that apply to the Standard apt-X variant only.

3) A Media type attributes embedded-aux=off/on that applies to the Enhanced apt-X variant only.

If there are no objections I'll update section 7 of internet draft with these changes. I will also update section 8 "IANA Considerations" with these new attribute registrations (Roni Even comments on draft-gmassey-avt-rtp-aptx-01, 6th May 2008 - http://www.ietf.org/mail-archive/web/avt/current/msg09586.html). __________________________________________________________________________________________________________________________________

I think there needs to be more discussion on whether synchronisation and auxilliary data should either hard configured into an agreed configuration for the internet-draft i.e. embedded-sync and embedded-aux always on, or whether they should be signalled in an accompanying SDP media type definition, i.e. as above. I personally prefer the flexibility of signalling but does this break the aims of RTP?

>> Colin Perkins wrote Apr 21 2008 (http://www.ietf.org/mail-archive/web/avt/current/msg09533.html)

>> 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)? 

 

Does anyone have any options on this? Colin?

 

Thanks Hans-Heinrich!