Internet DRAFT - draft-thatcher-avtcore-rtp-sframe

draft-thatcher-avtcore-rtp-sframe







Audio/Video Transport Core Maintenance                       P. Thatcher
Internet-Draft                                                 Microsoft
Intended status: Standards Track                            10 July 2023
Expires: 11 January 2024


                     RTP Payload Format for SFrame
                  draft-thatcher-avtcore-rtp-sframe-00

Abstract

   This document describes the RTP payload format of SFrame.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 January 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.








Thatcher                 Expires 11 January 2024                [Page 1]

Internet-Draft        RTP Payload Format for SFrame            July 2023


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   2
   3.  RTP Packetization of a media frame encrypted by SFrame  . . .   2
   4.  RTP depacketization of SFrame . . . . . . . . . . . . . . . .   3
   5.  SFrame payload type negotiation . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   SFrame [I-D.draft-ietf-sframe-enc-01] describes an end-to-end
   encryption and authentication mechanism for media frames in a
   multiparty conference call, in which central media servers (SFUs) can
   access the media metadata needed to make forwarding decisions without
   having access to the actual media.

   This document describes how to packetize a media frame encrypted
   using SFrame into RTP packets.

2.  Terminology and Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  RTP Packetization of a media frame encrypted by SFrame

   In order to packetize SFrame into RTP, packetization is done twice,
   once before SFrame encryption using media-format-specific RTP
   packetization into one large RTP packet, and once after SFrame
   encryption using SFrame-specific RTP packetization into many smaller
   RTP packets.  SFrame encryption is applied to the payload of output
   the media-format-specific RTP packetization, and SFrame-specific RTP
   packetization is applied to the output of the SFrame encryption.









Thatcher                 Expires 11 January 2024                [Page 2]

Internet-Draft        RTP Payload Format for SFrame            July 2023


   For example, if a media frame to be encrypted by SFrame is encoded
   using VP8, the media frame is first packetized according to [RFC7741]
   into one big RTP packet.  The VP8 RTP payload of the big RTP packet
   is then encrypted using SFrame, resulting in an SFrame-encrypted RTP
   payload of VP8.  SFrame-specific packetization is then applied to
   SFrame-encrypted RTP payload of VP8, resulting in many smaller RTP
   packets.

   SFrame-specific packetization is done by first breaking up the output
   of SFrame encryption into fragments, and then prepending some
   fragment metadata necessary for depacketization.  Finally, fragments
   are combined with values from the RTP header of the output of the
   media-format-specific packetization.

   The SFrame-specific RTP payloads (fragments with prepended metadata)
   have the following format:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L| media PT    |  media frame ID               |
   | fragment index                |  fragment ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The media PT must be the payload type of the output of the media-
   format-specific packetization.  The frame index of the first fragment
   of each media frame MUST be 0.  The frame index of each subsequent
   fragment MUST be one more than the previous fragment.  The L bit MUST
   be 0 for all fragments except for the last one of the media frame.
   The media frame ID must be unique enough that a depacketizer may be
   able to differentiate the fragments of one media frame from another.
   The SSRC, timestamp, marker bit, CSRCs, and header extensions of the
   SFrame RTP packets MUST be the same as those of the output of the
   media-format-specific packetization The payload type of the SFrame
   RTP packets must be a payload type that indicates the payload is
   format defined in this document, and it must have a negotiated RTP
   clock rate that is the same as the media-format-specific RTP packet.

4.  RTP depacketization of SFrame

   Depacketization is done by doing the packetization process in
   reverse:

   1.  The fragments of a given media frame ID are grouped together in
       order of fragment index and concatenated together, resulting in a
       media frame encrypted by SFrame.





Thatcher                 Expires 11 January 2024                [Page 3]

Internet-Draft        RTP Payload Format for SFrame            July 2023


   2.  The media frame is decrypted using SFrame, resulting in a big
       codec-specific RTP payload.

   3.  The big codec-specific RTP payload is combined with the RTP
       headers of the RTP packet with fragment index 0, resulting in a
       big media-format-specific RTP packet.  The "media PT" from the
       SFrame RTP payload header is used as the payload type of the
       result.

   4.  The big media-format-specific RTP packet is passed in a codec-
       specific RTP depacetizer, resulting in a media frame.

5.  SFrame payload type negotiation

   Because the payload type of an RTP packet that results from SFrame-
   specific packetization must match the clock rate of the payload type
   of the RTP packet that results from media-format-specific
   packetization, it may be necessary to negotiate more than one SFrame
   payload type.  For example, if one were to use SDP to negotiate
   payload types, the following payload types could be negotiated with
   different clock rates:

   m=audio 50000 RTP/SAVPF 96
   a=rtpmap:96 sframe/48000
   m=video 50002 RTP/SAVPF 97
   a=rtpmap:97 sframe/90000

6.  Security Considerations

   This document is subject to the security considerations of SFrame.

7.  IANA Considerations

   None

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7741]  Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
              Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
              DOI 10.17487/RFC7741, March 2016,
              <https://www.rfc-editor.org/rfc/rfc7741>.



Thatcher                 Expires 11 January 2024                [Page 4]

Internet-Draft        RTP Payload Format for SFrame            July 2023


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [I-D.draft-ietf-sframe-enc-01]
              Omara, E., Uberti, J., Murillo, S. G., Barnes, R., and Y.
              Fablet, "Secure Frame (SFrame)", Work in Progress,
              Internet-Draft, draft-ietf-sframe-enc-01, 13 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sframe-
              enc-01>.

Author's Address

   Peter Thatcher
   Microsoft
   Email: pthatcher@microsoft.com

































Thatcher                 Expires 11 January 2024                [Page 5]