Re: [AVTCORE] Call for Adoption: "RTP Payload Format for the SCIP Codec"

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

Bernard,

Responses to comments are below prefaced with [dh].


Regards,
Dan Hanson
General Dynamics Mission Systems

From: avt <[e-mail]> On Behalf Of Bernard Aboba
Sent: Wednesday, January 19, 2022 7:37 PM
To: IETF AVTCore WG <[e-mail]>
Subject: Re: [AVTCORE] Call for Adoption: "RTP Payload Format for the SCIP Codec"

External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I support adoption of "RTP Payload Format for the SCIP Codec" as an AVTCORE WG Work Item.

In reading draft-hanson-avtcore-rtp-scip, I have the following comments:

Section 4.1

" The RTP header fields SHOULD conform to RFC 3550. This is a SHOULD rather than a SHALL in recognition that legacy SCIP-enabled products may not strictly adhere to RFC 3550."

[BA] As I understand it, one of the goals of this specification is to improve the interoperability of SCIP implementations.  Many of the devices you are looking to interoperate with (e.g. RTP relays) will assume conformance to RFC 3550.  So if you are looking to improve interoperation with legacy SCIP implementations (particularly if you are expecting RTP implementations to make code changes) you are going to need to go into detail about how legacy SCIP-enabled products might violate RFC 3550.   Or are you only expecting RFC 3550-conformant SCIP implementations to interoperate?  If so, the SHOULD can be strengthened.

[dh] We will change the SHOULD to a SHALL and delete the second sentence. The intent of this statement was to allow leeway for some early SCIP implementations that may not have fully compliant.  But the SCIP Working Group will be able to manage these devices going forward.

" The RTP header fields SHALL conform to RFC 3550. "




         The Marker bit SHOULD be set to zero for discontinuous traffic.

         The Marker bit for continuous traffic is based on the

         underlying media subtype specification.  This specification is

         a SHOULD rather than a SHALL in recognition that legacy SCIP-

         enabled products may not strictly adhere to the media subtype

         specification.

[BA] This seems like an "unusual" usage of the Marker bit.  Given that Marker bit usage has been the cause of interop issues in video, would we expect this "unusual" usage in video traffic, or just audio?  My concern is whether this usage of the Marker bit might cause issues, even if the RTP implementation isn't parsing the traffic.  I realize that we've been long encouraging implementations to not require the Marker bit to be set correctly, but there are probably still implementations that do.

[dh] We will change the SHOULD to a SHALL and delete the third sentence.  The intent was to state that for discontinuous traffic, described in Section 2 as the media and security negotiation phase, the marker bit should be zero since that data has no timestamp meaning.  Previous versions of SCIP-214 did not define usage of the marker bit.  Currently, "audio/scip" only supports MELPe (RFC8130) and G.729d (RFC3551).  MELPe does not define marker bit setting.  G.729d defines marker bit settings for talkspurts.  For "video/scip", H.264 (RFC6184) defines the market bit settings.


         The Marker bit SHALL be set to zero for discontinuous traffic.  The Marker bit for continuous traffic is based on the

         underlying media subtype specification.


Section 5


         A clock rate of 8000 Hz SHALL be used for "audio/scip".
[BA] Is the audio clock rate used by the codec always 8000?  For example, is it not possible to negotiate Opus within SCIP?  Negotiating a codec within SCIP with an alternative clock rate while only indicating 8000 in SDP seems like it could lead to potential interop issues.

[dh] Currently, "audio/scip" only supports MELPe and G.729d which both use 8000 Hz.  The SCIP WG has no current plans to add more audio codecs.


Section 5.1


         Interoperability considerations: N/A

[BA] I think you're going to need to go into more detail here.

[dh] Our interpretation of "Interoperability considerations" was interoperability with previous versions of the SCIP specification.  Since this is the first version of the SCIP RFC/IANA RTP registration, we felt "N/A" was the appropriate response.




On Wed, Jan 12, 2022 at 6:45 AM Bernard Aboba <[e-mail]<mailto:[e-mail]>> wrote:
This is a call for adoption of "RTP Payload Format for the SCIP Codec" as an AVTCORE WG Work item.

The document is available for inspection here:
draft-hanson-avtcore-rtp-scip-00 - RTP Payload Format for the SCIP Codec (ietf.org)<https://datatracker.ietf.org/doc/draft-hanson-avtcore-rtp-scip/>

The Call for Adoption will last until January 26, 2022 at midnight Pacific TIme.

Please respond to this CfA with one of the following:

* I support adoption of "RTP Payload Format for the SCIP Codec" as an AVTCORE WG Work item.

* I object to adoption of "RTP Payload Format for the SCIP Codec" as an AVTCORE WG Work Item, due to the following issues <list of issues>.