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

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Jan 2022 06:45:38 -0800

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>.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 19 Jan 2022 19:57:27 +0000

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

Dan Hanson
General Dynamics Mission Systems

From: avt <[email-masked]> On Behalf Of Bernard Aboba
Sent: Wednesday, January 12, 2022 9:46 AM
To: IETF AVTCore WG <[email-masked]>
Subject: [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.

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.

* 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>.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jan 2022 16:37:18 -0800

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.

         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.

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.

Section 5.1

         Interoperability considerations: N/A

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

On Wed, Jan 12, 2022 at 6:45 AM Bernard Aboba <[email-masked]>
wrote:

> (ietf.org)
> <https://datatracker.ietf.org/doc/draft-hanson-avtcore-rtp-scip/>
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 21 Jan 2022 01:00:41 +0000

One small recommendation that I think could save you lots of headache in discussion of this draft: I think the references to  [SCIP210] and [SCIP214]  should be informative not normative. One does not need to understand them to implement the RTP portion of this and some devices can do things like record or relay without encoding or decoding the SCIP. We have done this with other RTP payloads and clearly making them non normative will avoid discussions about availability of specifications. 

Cullen Jennings, CTO of Security & Collaboration at Cisco 

> On Jan 12, 2022, at 7:45 AM, Bernard Aboba <[email-masked]> wrote:
> 
> draft-hanson-avtcore-rtp-scip-00 - RTP Payload Format for the SCIP Codec (ietf.org)
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 26 Jan 2022 09:35:48 +1300

> On Jan 21, 2022, at 2:00 PM, Cullen Jennings (fluffy) <fluffy=[email-masked]> wrote:
> 

This is an important point.  To expand upon this: Is it possible - without having access to the SCIP specifications - to implement a server that can take an otherwise opaque SCIP byte stream, packetize it, and transmit it via RTP?  Similarly, is it possible - without having the SCIP specifications - to implement a receiver that takes a SCIP-over-RTP packet stream, and record its data into a usable file?

If the answers to these questions is “no” or “not quite", then some text (basically, packetization/depacketization hints) should be added to the RTP Payload Format document to make these things possible, without accessing the SCIP specification.  With this caveat, I support adoption of this document as an AVTCORE WG work item.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 31 Jan 2022 16:18:41 +0000

Ross,

Thanks for you comments. Our responses are below prefaced with [dh].

Regards,
Dan Hanson

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Ross Finlayson
Sent: Tuesday, January 25, 2022 3:36 PM
To: IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] Call for Adoption: "RTP Payload Format for the SCIP Codec"

----

> One small recommendation that I think could save you lots of headache in discussion of this draft: I think the references to  [SCIP210] and [SCIP214]  should be informative not normative. One does…

[dh] We will move the references for [SCIP210] and [SCIP214] to the informative section.

[dh] SCIP is a two-way application-layer protocol; it is not a one-way "stream" of data.  A network device should not attempt to repacketize it because that affect the agreed upon RTP parameters such as 'ptime'.  Recording the SCIP stream to a file is not practical because the protocol is two-way.

If the answers to these questions is "no" or "not quite", then some text (basically, packetization/depacketization hints) should be added to the RTP Payload Format document to make these things possible, without accessing the SCIP specification.  With this caveat, I support adoption of this document as an AVTCORE WG work item.

[dh] We can add text to discourage packetization/depacketization of the SCIP stream.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 31 Jan 2022 16:20:46 +0000

Cullen,

We will move the references for [SCIP210] and [SCIP214] to the informative section.

Regards,
Dan Hanson

-----Original Message-----
From: Cullen Jennings (fluffy) <[email-masked]> 
Sent: Thursday, January 20, 2022 8:01 PM
To: IETF AVTCore WG <[email-masked]>
Cc: Hanson, Daniel C <[email-masked]>; Bernard Aboba <[email-masked]>
Subject: Re: [AVTCORE] Call for Adoption: "RTP Payload Format for the SCIP Codec"

----

> Audio/Video Transport Core Maintenance [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 31 Jan 2022 17:10:22 +0000

Bernard,

Responses to comments are below prefaced with [dh].

Regards,
Dan Hanson

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

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

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. "

         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

[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 <[email-masked]<mailto:[email-masked]>> wrote:
This is a call for adoption of "RTP Payload Format for the SCIP Codec" as an AVTCORE WG Work item.