Abstract

Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider.¶

1. Introduction

Video Relay Service (VRS) is a form of Telecommunications Relay Service (TRS) that enables people with hearing disabilities who use sign language, such as American Sign Language (ASL), to communicate with voice telephone users through video equipment. These services also enable communication between such individuals directly in suitable modalities, including any combination of sign language via video, real-time text, and speech.¶

This interoperability profile for Relay User Equipment (RUE) is a profile of the Session Initiation Protocol (SIP) and related media protocols that enables end-user equipment registration and calling for VRS calls. It specifies the minimal set of call flows and IETF and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and extended capabilities for RUE calls.¶

Both subscriber-to-provider (interpreted) and direct subscriber-to-subscriber calls are supported on this interface. While there are some accommodations in this document to maximize backwards compatibility with other devices and services that are used to provide VRS service, backwards compatibility is not a requirement, and some interwork may be required to allow direct video calls to older devices. This document only describes the interface between the device and the provider, not any other interface the provider may have.¶

The following illustrates a typical relay call. The RUE device and the communications assistant (sign language interpreter) have videophones. The hearing user has a telephone (mobile or fixed).¶

                           ||== RUE Interface (this document)
                           ||
                           \/
  +------+   +------+      -       +--------+     -      +-------+
  |User  |   |RUE   |    (   )     |Provider|    (  )    |User   |
  |who is|   |Device|<-(Internet)->|        |            |who is |
  |Deaf  |<->|      |              |        |<-( PSTN )->|Hearing|
  +------+   +------+   --------   +--------+   ------   +-------+
                                        ^
                                        |
                                +--------------+
                                |Communications|
                                |Assistant     |
                                +--------------+

2. Terminology

Communications Assistant (CA):

A sign-language interpreter working for a VRS provider, providing functionally equivalent phone service.¶

Communication modality (modality):

A specific form of communication that may be employed by two users, e.g., English voice, Spanish voice, American Sign Language, English lipreading, or French real-time text. Here, one communication modality is assumed to encompass both the language and the way that language is exchanged. For example, English voice and French voice are two different communication modalities.¶

Default video relay service:

The video relay service operated by a subscriber's default VRS provider.¶

Default video relay service provider (default provider):

The VRS provider that registers and assigns a telephone number to a specific subscriber and, by default, provides the VRS for incoming voice calls to the user. The default provider, also by default, provides the VRS for outgoing relay calls. The user can have more than one telephone number, and each has a default provider.¶

Outbound dial-around call:

A relay call where the subscriber specifies the use of a VRS provider other than the default VRS provider. This can be accomplished by the user dialing a "front-door" number for a VRS provider and signing or texting a phone number to call ("two-stage"). Alternatively, this can be accomplished by the user's RUE software instructing the server of its default VRS provider to automatically route the call through the alternate provider to the desired Public Switched Telephone Network (PSTN) directory number ("one-stage"). Dial-around is per call; for any call, a user can use the default VRS provider or any dial-around VRS provider.¶

Full Intra Request (FIR):

A request to a video media sender, requiring that media sender to send a decoder refresh point at the earliest opportunity. FIR is sometimes known as "instantaneous decoder refresh request", "video fast update request", or "fast update request".¶

Point-to-Point Call (P2P Call):

A call between two RUEs, without including a CA.¶

Relay call:

A call that allows people with hearing or speech disabilities to use a RUE to talk to users of conventional voice services with the aid of a CA to relay the communication.¶

Relay service (RS):

A service that allows a registered subscriber to use a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay calls. The functions provided by the relay service include the provision of media links supporting the communication modalities used by the caller and callee, user registration and validation, authentication, authorization, automatic call distributor (ACD) platform functions, routing (including emergency call routing), call setup, mapping, call features (such as call forwarding and video mail), and assignment of CAs to relay calls.¶

Relay service provider (provider):

An organization that operates a relay service. A subscriber selects a relay service provider to assign and register a telephone number for their use, to register with for receipt of incoming calls, and to provide the default service for outgoing calls.¶

Relay user:

Please refer to "subscriber".¶

Relay user E.164 Number (user E.164):

The telephone number (in ITU-T E.164 format) assigned to the user.¶

Relay User Equipment (RUE):

A SIP user agent (UA) enhanced with extra features to support a subscriber in requesting, receiving, and using relay calls. A RUE may take many forms, including a stand-alone device; an application running on a general-purpose computing device, such as a laptop, tablet, or smartphone; or proprietary equipment connected to a server that provides the RUE interface.¶

RUE interface:

The interfaces described in this document between a RUE and a VRS provider who supports it.¶

Sign language:

A language that uses hand gestures and body language to convey meaning, including, but not limited to, American Sign Language (ASL).¶

Subscriber:

An individual who has registered with a provider and who obtains service by using a RUE. This is the conventional telecom term for an end-user customer, which in this case is a relay user. A user may be a subscriber to more than one VRS provider.¶

Video Relay Service (VRS):

A relay service for people with hearing or speech disabilities who use sign language to communicate using video equipment (video RUE) with other people in real time. The video link allows the CA to view and interpret the subscriber's signed conversation and relay the conversation back and forth with the other party.¶

3. Requirements Language

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. Lower- or mixed-case uses of these key words are not to be interpreted as carrying special significance.¶

9. Provisioning and Provider Selection

To simplify how users interact with RUE devices, the RUE interface separates provisioning into two parts. One provides a directory of providers so that a user interface can allow easy provider selection either for registering or for dial-around. The other provides configuration data for the device for each provider.¶

{
  "providers": [
    {
      "name": "Red",
      "entryPoint": "red.example.net"
    },
    {
      "name": "Green",
      "entryPoint": "green.example.net"
    },
    {
      "name": "Blue",
      "entryPoint": "blue.example.net"
    }
  ]
}

{
  "versions": [
    {
     "major": 1,
     "minor": 6
    },
    {
     "major": 2,
     "minor": 13
    },
    {
     "major": 3,
     "minor": 2
    }
  ]
}

{
  "signUp": [
     { "language" : "en", "uri" : "https:hello-en.example.net"},
     { "language" : "es", "uri" : "https:hello-es.example.net"} ] ,
  "dial-around": [
     { "language" : "en", "front-door" : "sip:fd-en.example.net",
          "oneStage" : "sip:1stg-eng.example.com" } ,
     { "language" : "es", "front-door" : "sip:fd-es.example.net",
          "oneStage" : "sip:1stg-spn.example.com" } ] ,
  "helpDesk": [
     { "language" : "en", "uri" : "sip:help-en.example.net"} ,
     { "language" : "es", "uri" : "sip:help-es.example.net"} ]
}

{
  "lifetime": 86400,
  "display-name" : "Bob Smith",
  "phone-number": "+15551234567",
  "provider-domain": "red.example.net",
  "outbound-proxies": [
    "sip:p1.red.example.net",
    "sip:p2.red.example.net" ],
  "mwi": "sip:[email protected];user=phone",
  "videomail": "sip:[email protected];user=phone",
  "contacts": {
    "contacts-uri":
       "https://red.example.net:443/c/3617b719-2c3a-46f4-9c13",
    "contacts-username": "bob",
    "contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb"
  },
  "carddav": {
     "carddav-domain": "carddav.example.com",
     "carddav-username": "bob",
     "carddav-password": "sj887%dd*jJty%87hyys5hHT"
  },
  "sendLocationWithRegistration": false,
  "ice-servers": [
     {"stun":"stun.red.example.com:19302" },
     {"turn":"turn.red.example.com:3478"}
  ]
}

openapi: 3.0.1
info:
  title: RUM Provider List API
  version: "1.0"
servers:
  - url: https://localhost/rum/v1
paths:
  /Providers:
    get:
      summary: Get a list of providers and domains to get
               config data from
      operationId: GetProviderList
      responses:
        '200':
          description: List of providers for a country
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProviderList'
  /Versions:
    servers:
      - url: https://localhost/rum
        description: Override base path for Versions query
    get:
      summary: Retrieves all supported versions
      operationId: RetrieveVersions
      responses:
        '200':
          description: Versions supported
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/VersionsArray'
components:
  schemas:
    ProviderList:
      type: object
      required:
        - providers
      properties:
        providers:
          type: array
          items:
            type: object
            required:
              - name
              - providerEntryPoint
            properties:
              name:
                type: string
                description: Human-readable provider name
              providerEntryPoint:
                type: string
                description: Provider entry point for interface
    VersionsArray:
      type: object
      required:
        - versions
      properties:
        versions:
          type: array
          items:
            type: object
            required:
              - major
              - minor
            properties:
              major:
                type: integer
                format: int32
                description: Version major number
              minor:
                type: integer
                format: int32
                description: Version minor number

openapi: 3.0.1
info:
  title: RUM Configuration API
  version: "1.0"
servers:
  - url: https://localhost/rum/v1
paths:
  /ProviderConfig:
    get:
      summary: Configuration data for one provider
      operationId: GetProviderConfiguration
      parameters:
        - in: query
          name: apiKey
          schema:
            type: string
          description: API Key assigned to this implementation
        - in: query
          name: instanceId
          schema:
            type: string
          required: true
          description: Unique string for this implementation
                       on this device
      responses:
        '200':
          description: Configuration object
          content:
            application/json:
              schema:
                $ref:
                 '#/components/schemas/ProviderConfigurationData'
  /RueConfig:
    get:
      summary: Configuration data for one RUE
      operationId: GetRueConfiguration
      parameters:
        - in: query
          name: apiKey
          schema:
            type: string
          description: API Key assigned to this implementation
        - in: query
          name: instanceId
          schema:
            type: string
          required: true
          description: Unique string for this implementation
                       on this device
      responses:
        '200':
          description: Configuration object
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RueConfigurationData'
  /Versions:
    servers:
      - url: https://localhost/rum
        description: Override base path for Versions query
    get:
      summary: Retrieves all supported versions
      operationId: RetrieveVersions
      responses:
        '200':
          description: Versions supported
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/VersionsArray'
components:
  schemas:
    ProviderConfigurationData:
      type: object
      required:
        - dial-around
      properties:
        signup:
          type: array
          items:
            type: object
            required:
              - language
              - uri
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                  Registry"
              uri:
                type: string
                format: uri
                description: URI to signup website supporting
                  this language
        dial-around:
          type: array
          items:
            type: object
            required:
              - language
              - front-door
              - oneStage
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                  Registry"
              front-door:
                type: string
                format: uri
                description: SIP URI for two-stage dial-around
              oneStage:
                type: string
                format: uri
                description: SIP URI for one-stage dial-around
        helpDesk:
          type: array
          items:
            type: object
            required:
              - language
              - uri
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                   Registry"
              uri:
                type: string
                format: uri
                description: SIP URI of help desk supporting language
    RueConfigurationData:
      type: object
      required:
        - phone-number
        - provider-domain
      properties:
        lifetime:
          type: integer
          description: How long (in seconds) the RUE MAY cache the
                       configuration values
        sip-password:
          type: string
        phone-number:
          type: string
          description: Telephone number assigned this subscriber in
            E.164 format
        user-name:
          type: string
          description: A username assigned to this subscriber
        display-name:
          type: string
          description: Display name for the subscriber
        provider-domain:
          type: string
          description: Domain of the provider for this subscriber
        outbound-proxies:
          type: array
          items:
             type: string
             format: uri
             description: SIP URI of a proxy to be used when sending
                       requests to the provider
        mwi:
          type: string
          format: uri
          description: A URI identifying a SIP event server that
              generates "message-summary" events for this subscriber
        videomail:
          type: string
          format: uri
          description: An HTTPS or SIP URI that can be used to
                       retrieve video mail messages
        contacts:
          type: object
          description: Server and credentials for contact
             import/export
          required:
            - contacts-uri
          properties:
            contacts-uri:
              type: string
              format: uri
              description: An HTTPS URI that may be used to export
                (retrieve) the subscriber's complete contact list
                managed by the provider
            contacts-username:
              type: string
              description: Username for authentication with the
                CardDAV server.  Use SIP user-name if not provided
            contacts-password:
              type: string
              description: Password for authentication. Use provider
                sip-password if not provided
        carddav:
          type: object
          description: CardDAV server and user information that can
               be used to synchronize the RUE's contact list with
               the contact list managed by the provider
          required:
            - carddav-domain
          properties:
            carddav-domain:
              type: string
              description: CardDAV server address
            carddav-username:
              type: string
              description: Username for authentication with the
                 CardDAV server.  Use SIP user-name if not provided
            carddav-password:
              type: string
              description: Password for authentication to the CardDAV
                 server. Use provider sip-password if not provided
        sendLocationWithRegistration:
          type: boolean
          description: True if the RUE should send a Geolocation
               header field with REGISTER; false if it should not.
               Defaults to false if not present
        ice-servers:
          type: array
          items:
            type: object
            required:
              - server-type
              - uri
            properties:
              server-type:
                type: string
                description: Server type ("stun" or "turn")
              uri:
                type: string
                format: uri
                description: URIs identifying STUN and TURN servers
                  available for use by the RUE for establishing
                  media streams in calls via the provider
    VersionsArray:
      type: object
      required:
        - versions
      properties:
        versions:
          type: array
          items:
            type: object
            required:
              - major
              - minor
            properties:
              major:
                type: integer
                format: int32
                description: Version major number
              minor:
                type: integer
                format: int32
                description: Version minor number

12. Normative References

[OpenAPI]

Miller, D., Whitlock, J., Gardiner, M., Ralphson, M., Ratovsky, R., and U. Sarid, "OpenAPI Specification v3.0.1", December 2017, <https://spec.openapis.org/oas/v3.0.1>.

[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/info/rfc2119>.

[RFC2392]

Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>.

[RFC3261]

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC3263]

Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.

[RFC3264]

Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.

[RFC3311]

Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, <https://www.rfc-editor.org/info/rfc3311>.

[RFC3323]

Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.

[RFC3326]

Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <https://www.rfc-editor.org/info/rfc3326>.

[RFC3327]

Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, <https://www.rfc-editor.org/info/rfc3327>.

[RFC3458]

Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, DOI 10.17487/RFC3458, January 2003, <https://www.rfc-editor.org/info/rfc3458>.

[RFC3515]

Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <https://www.rfc-editor.org/info/rfc3515>.

[RFC3605]

Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-editor.org/info/rfc3605>.

[RFC3840]

Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <https://www.rfc-editor.org/info/rfc3840>.

[RFC3842]

Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 2004, <https://www.rfc-editor.org/info/rfc3842>.

[RFC3891]

Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <https://www.rfc-editor.org/info/rfc3891>.

[RFC3892]

Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, September 2004, <https://www.rfc-editor.org/info/rfc3892>.

[RFC3960]

Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, <https://www.rfc-editor.org/info/rfc3960>.

[RFC3966]

Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>.

[RFC4102]

Jones, P., "Registration of the text/red MIME Sub-Type", RFC 4102, DOI 10.17487/RFC4102, June 2005, <https://www.rfc-editor.org/info/rfc4102>.

[RFC4103]

Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.

[RFC4488]

Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, DOI 10.17487/RFC4488, May 2006, <https://www.rfc-editor.org/info/rfc4488>.

[RFC4585]

Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.

[RFC4733]

Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, <https://www.rfc-editor.org/info/rfc4733>.

[RFC4967]

Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, DOI 10.17487/RFC4967, July 2007, <https://www.rfc-editor.org/info/rfc4967>.

[RFC5104]

Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <https://www.rfc-editor.org/info/rfc5104>.

[RFC5168]

Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, DOI 10.17487/RFC5168, March 2008, <https://www.rfc-editor.org/info/rfc5168>.

[RFC5393]

Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, DOI 10.17487/RFC5393, December 2008, <https://www.rfc-editor.org/info/rfc5393>.

[RFC5626]

Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>.

[RFC5658]

Froment, T., Lebel, C., and B. Bonnaerens, "Addressing Record-Route Issues in the Session Initiation Protocol (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, <https://www.rfc-editor.org/info/rfc5658>.

[RFC5954]

Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, <https://www.rfc-editor.org/info/rfc5954>.

[RFC6263]

Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <https://www.rfc-editor.org/info/rfc6263>.

[RFC6351]

Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, <https://www.rfc-editor.org/info/rfc6351>.

[RFC6352]

Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011, <https://www.rfc-editor.org/info/rfc6352>.

[RFC6442]

Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-editor.org/info/rfc6442>.

[RFC6665]

Roach, A.B., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <https://www.rfc-editor.org/info/rfc6665>.

[RFC6764]

Daboo, C., "Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, <https://www.rfc-editor.org/info/rfc6764>.

[RFC6881]

Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, <https://www.rfc-editor.org/info/rfc6881>.

[RFC7525]

Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC7647]

Sparks, R. and A.B. Roach, "Clarifications for the Use of REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, September 2015, <https://www.rfc-editor.org/info/rfc7647>.

[RFC7742]

Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, <https://www.rfc-editor.org/info/rfc7742>.

[RFC7852]

Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>.

[RFC7874]

Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, <https://www.rfc-editor.org/info/rfc7874>.

[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/info/rfc8174>.

[RFC8445]

Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8599]

Holmberg, C. and M. Arnold, "Push Notification with the Session Initiation Protocol (SIP)", RFC 8599, DOI 10.17487/RFC8599, May 2019, <https://www.rfc-editor.org/info/rfc8599>.

[RFC8760]

Shekh-Yusef, R., "The Session Initiation Protocol (SIP) Digest Access Authentication Scheme", RFC 8760, DOI 10.17487/RFC8760, March 2020, <https://www.rfc-editor.org/info/rfc8760>.

[RFC8825]

Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.

[RFC8827]

Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.

[RFC8829]

Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, <https://www.rfc-editor.org/info/rfc8829>.

[RFC8834]

Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, <https://www.rfc-editor.org/info/rfc8834>.

[RFC8835]

Alvestrand, H., "Transports for WebRTC", RFC 8835, DOI 10.17487/RFC8835, January 2021, <https://www.rfc-editor.org/info/rfc8835>.

[RFC8839]

Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, <https://www.rfc-editor.org/info/rfc8839>.

[RFC8865]

Holmberg, C. and G. Hellström, "T.140 Real-Time Text Conversation over WebRTC Data Channels", RFC 8865, DOI 10.17487/RFC8865, January 2021, <https://www.rfc-editor.org/info/rfc8865>.

[RFC8866]

Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.

[RFC9071]

Hellström, G., "RTP-Mixer Formatting of Multiparty Real-Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, <https://www.rfc-editor.org/info/rfc9071>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[RFC9112]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.

13. Informative References

[RFC3665]

Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, December 2003, <https://www.rfc-editor.org/info/rfc3665>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.