Skip to main content

RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec



Murray Kucherawy

No Objection

Erik Kline
Paul Wouters


No Record

Jim Guichard
Martin Duke
Warren Kumari

Summary: Has 3 DISCUSSes. Needs 4 more YES or NO OBJECTION positions to pass.

Lars Eggert
Discuss (2023-08-04 for -05) Sent
# GEN AD review of draft-ietf-avtcore-rtp-scip-05

CC @larseggert

Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review

# Discuss

I don't think this document should be published on the Standards Track
without a normative reference to [SCIP210], and without that document
being made available in some form during IETF review.

If [SCIP210] cannot be made available, a way forward might be to publish
this specification as an Informational RFC and to add explicit text about
the limited review it has hence received by the IETF.
Comment (2023-08-04 for -05) Sent
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 5.3, paragraph 9
TP in general. This responsibility lays on anyone using RTP in an application
Did you mean "lies on"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

Zaheduzzaman Sarker
Discuss (2023-01-05 for -04) Sent
Thanks for working on this specification. My understanding is that SCIP is not a typical audio/video codec and intention here is to defice  a payload format used along with other audio/video codecs. Thanks to Olivier Bonaventure for an excellent TSVART review.

I would like to discuss the followings -

- It is not clear to me what RTP profile should be used with this payload format. The RTP profiles are mentioned only in the security considerations. I think this specification would not be sufficient to be implemented without specifying the profile usage. I am getting that all the control messages are sent as SCIP messages, hence it needs to be clear on the RTP/RTCP usage.

- This statement needs to be clarified more -

    "SCIP traffic is highly variable and the bit rate specified in the SDP [RFC8866] is OPTIONAL since discontinuous transmission (DTX) or other mechanisms may be used."  

  What does this "highly variable" traffic mean? In what sense it is variable, variable bitrate? if this is highly variable how this would react to congestion and rate control?

  what bitrate is specified in the SDP? are you talking about the "b" parameter and interpretation of that? how is that to be interpreted in the session level and media level due to DTX?

- it says -

    "a jitter buffer MAY be implemented in endpoint devices only"

  Given that "both discontinuous and continuous traffic are highly probable", a jitter buffer is a MAY? How to handle late loss or reordering? is it expected that no transmission error possible in the environment where SCIP operates?

-  what is the plan to include the changes agreed to with the TSVART reviewer? I mostly agreed with the resolution agreed with the reviewer and would like to see those changes in the document before we approve this document. That is the reason I am not bringing those topics back in this discuss. Please consider them as my discuss points as well.
Comment (2023-01-05 for -04) Sent
Some further comments -

- Please add a link to SCIP specification, I had hard time finding public description or documentation of SCIP codecs.

- I think it would be great to provide the design principles behind SCIP with some details. This will be helpful for understanding the motivation and rtp format specified in the document.
Éric Vyncke
Discuss (2023-08-04 for -05) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05

Thank you for the work put into this document. 

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Bernard Aboba for the shepherd's detailed write-up including the WG consensus ***but it lacks*** the justification of the intended status, this is related to my DISCUSS below. 

I hope that this review helps to improve the document,




As noted in, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 2

I am afraid that without free and public access to the IETF community (whether informational or normative) to the SCIP protocol itself, the IETF stream cannot publish any document (even informational or experimental) with the following assertion/claim `These capabilities include end-to-end security at the application layer, authentication of user identity,`. Suggest removing any such claim from the text.
Comment (2023-08-04 for -05) Sent

## Abstract

Is there a reason why is SDP expanded and not RTP ?

## Section 1

Unsure whether the following text has a place into an IETF RFC `This document provides a reference for network security policymakers, network equipment OEMs, procurement personnel, and government agency and commercial industry representatives.`. Suggest to remove it.

I wonder to wonder whether the USA has left NATO ? The text `SCIP is presently implemented in United States and NATO` seems to indicate that the USA are not included in NATO.

## Section 1.2

The DTX acronym is expanded twice and never used. Suggest to remove it.

## Section 2

Per `Secure Communication Interoperability Protocol (SCIP) allows the negotiation of several voice, data, and video applications`, it appears that SCIP can also be used for *data*, but this document is only about video/audio. I.e., some text should explain to the reader what happens to the data.

Please explain what is a STANAG or provide an informational reference to STANAG 5068.

The reader will welcome explanations about the numbers in `scip/8000 and scip/90000` (e.g., by a reference to section 5)

## Section 3.1

Should there be informative references for MELPe, G.729D ?

Is this subsection useful ? This document is about RTP payload and this subsection is more fit for the SCIP endpoints themselves. But, I am neither a transport nor an application expert, so, feel free to keep this subsection.


The official name of the UNO member state is "United States of America" and not simply "United States".
Murray Kucherawy
Erik Kline
No Objection
Francesca Palombini
(was Discuss, No Objection) No Objection
Comment (2023-03-25 for -04) Sent for earlier
Clearing my DISCUSS in order to not block document progress, however I trust the responsible AD will make sure it is addressed - see thread here:

==== Previous ballot =====


Apologies for the delayed DISCUSS ballot. I just wanted to bring a process question up before the document moves forward.

Since this document will be the reference RFC for two existing media type registrations, I wonder if the change controller should be changed to IETF instead of the SCIP wg. In practice this would mean that any change to the registration would need to go through the IETF, which might make inconsistency between the RFC of reference and the registrations less likely.


Thank you for the work on this document. I also read this document without reading the SCIP spec, as that spec is referenced informatively.

Many thanks to Jim Fenton for his ART ART reviews: and, and to the authors for addressing Jim's comments.
John Scudder
No Objection
Comment (2023-12-05) Sent
I have a couple small questions/nits with respect to this sentence in the abstract:

                  SCIP is considered a
   tunneling protocol where the contents of the RTP payload will be
   indeterminant and should not be filtered or altered by the network.

Question: do you actually mean “tunneling protocol“ and not “tunneled protocol“? When I read “tunneling protocol“, I think of something like LISP, IPSec tunnel mode, etc — a general purpose facility for transporting data. As far as I can tell from the rest of the spec, what you actually mean is that the SCIP payload is tunneled inside RTP. Please correct if appropriate.

Nit: some of the dictionaries I consulted didn’t think that “indeterminant“ was a word at all. Some of the more open-minded dictionaries allowed that it was a word, but with a meaning that is somewhat… indeterminant, shall we say. Probably the RFC editor would suggest a change to this anyway, but consider changing to something closer to standard English if possible.
Paul Wouters
No Objection
Robert Wilton
No Objection
Comment (2023-01-05 for -04) Sent

(1) p 0, sec                                                                                                                                                                                                                                                                                                                                                                                 
   This document describes the RTP payload format of the Secure                                                                                                                                                                                                                                                                                                                              
   Communication Interoperability Protocol (SCIP).  SCIP is an                                                                                                                                                                                                                                                                                                                               
   application layer protocol that defines the establishment of reliable                                                                                                                                                                                                                                                                                                                     
   secure end-to-end communications, including capabilities exchange                                                                                                                                                                                                                                                                                                                         
   with secure session establishment parameters such as codec selection,                                                                                                                                                                                                                                                                                                                     
   encryption algorithms, security levels, and cryptographic                                                                                                                                                                                                                                                                                                                                 
   initialization values.  This document defines the Session Description                                                                                                                                                                                                                                                                                                                     
   Protocol (SDP) and RTP parameters needed to support SCIP over RTP.                                                                                                                                                                                                                                                                                                                        
I'm somewhat wondering why this is being published as standards track rather then informational given that the underlying protocol is not openly available.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               
Minor level comments:                                                                                                                                                                                                                                                                                                                                                                        
(2) p 4, sec 4.1.  RTP Header Fields                                                                                                                                                                                                                                                                                                                                                         
   SCIP traffic may be continuous or discontinuous.  The Timestamp field                                                                                                                                                                                                                                                                                                                     
   MUST increment based on the sampling clock for discontinuous                                                                                                                                                                                                                                                                                                                              
   transmission as described in [RFC3550], Section 5.1.  The Timestamp                                                                                                                                                                                                                                                                                                                       
   field for continuous transmission applications is dependent on the                                                                                                                                                                                                                                                                                                                        
   sampling rate of the media as specified in the media subtype's                                                                                                                                                                                                                                                                                                                            
   specification (e.g., MELPe [RFC8130]).  Note that during a SCIP                                                                                                                                                                                                                                                                                                                           
   session, both discontinuous and continuous traffic are highly                                                                                                                                                                                                                                                                                                                             
   probable.  Therefore, a jitter buffer MAY be implemented in endpoint                                                                                                                                                                                                                                                                                                                      
   devices only but SHOULD NOT be implemented in network devices.                                                                                                                                                                                                                                                                                                                            
   Additionally, network devices SHOULD NOT repacketize SCIP packets.                                                                                                                                                                                                                                                                                                                        
Please expand on what is meant by "repacketize SCIP packets".

Andrew Alston
(was No Objection) Abstain
Comment (2023-07-26 for -05) Not sent
After giving this thought, I have to agree with Roman's position on this, and hence, I am joining him in an abstention on this document.
Roman Danyliw
(was Discuss) Abstain
Comment (2023-07-26 for -05) Sent
(Revised position)

Thank you to Magnus Nystrom for the SECDIR review.

I am abstaining on this document as it is unclear to me how to evaluate this document.  Unlike most of the other recent “RTP Payload Format” document I could find, the text here avoids making a normative reference to a document formally describing a payload. Colloquially, I’m not sure how one can describe the “payload format of _something_” without normatively citing that _something_.  Furthermore, the security basis for this document comes from this informative reference.

The IETF 117 AVTCORE meeting discussions helpfully pointed out that RFC8817, a document I balloted on with a “No Objection” position, cites the codec it relies on informatively.  I appreciate the inconsistency of my position.  Simply put, I missed this detail in my review of RFC8817.  I’ll note that RFC8817 does normatively cite SCIP, albeit the 2013 version, and this document references 2017.  

In my assessment, this approach meets the DISCUSS criteria of “[t]he draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively” per  However, I won’t hold a document for reference mismatch as it is clear that the WG has discussed this issue in depth and there is IETF consensus on this way ahead.

Additional comments

** I would have appreciated additional justification for the proposed standard (PS) status either in the text or in the shepherd write-up.  The underlying codec is proprietary, neither available or intended for users outside of a closed consortium; and the need for standardization isn’t clear since this is intended for this closed consortium.  MIME registrations can be done without a PS in the IETF stream.

** Section 1.
   This document provides essential information about audio/scip and
   video/scip media subtypes that enables network equipment
   manufacturers to include settings for "scip" as a known audio and
   video media subtype in their equipment.  This enables network
   administrators to define and implement a compatible security policy

It wasn’t clear which text in this document was intended to inform the definition of security policies.

** Section 5.1 and 5.2.  The IANA review will clarify this, but the stated “Intended usage” of “Common, Government and Military” doesn’t seem consistent with the guidance in RFC6838 which says that:

   Intended usage:


** Section 5.1. and 5.2.  I concur with Francesca’s ballot which wonders why the IETF is registering a media type for which it has no change control and the challenges it might create.
Jim Guichard
No Record
Martin Duke
No Record
Warren Kumari
No Record
Alvaro Retana Former IESG member
No Objection
No Objection (2023-01-03 for -04) Not sent
[I support Roman's DISCUSS.]