Interoperability Profile for Relay User Equipment470 Conrad DrMarsPA16046US+1 724 382 1051br@brianrosen.net
art
rumrueVideo Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user 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 supplied 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 dead/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document describes the interface between a videophone and a provider.IntroductionVideo Relay Service (VRS) is a form of Telecommunications Relay Service (TRS) that enables persons 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 (RTT), 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, Internet Engineering Task Force (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 deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/HoH calls are supported on this interface. While there are some accommodations in this document to maximize backwards compatibility with devices and services that conform to this document, 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, and not any other interface the provider may have. Terminology
Communication Assistant (CA): The ASL interpreter stationed in a TRS-registered call center working for a VRS Provider,
acting as part of the wire of a call to provide 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 lip-reading, 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.
A subscriber's default Provider provides the VRS that handles incoming relay calls to the user. The default Provider also handles outgoing relay calls by default.
Dial-around call: A relay call where the subscriber specifies the use of a VRS provider other than one of the Providers with whom the subscriber is registered.
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").
Full Intra Request (FIR): A request to a 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 persons with hearing or speech disabilities to use a RUE to talk to users of traditional voice services with the aid of a communication assistant (CA) to relay the communication. Please refer to FCC-VRS-GUIDE.
Relay-to-relay call: A call between two subscribers each using different forms of relay (video relay, IP relay, TTY), each with a separate CA to assist in relaying the conversation.
Relay service (RS): A service that allow 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, and 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 assigned to the RUE in ITU-T E.164 format.
Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra features to support a subscriber in requesting 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 smart phone; or proprietary equipment connected to a server that provides the RUE interface.
RUE Interface: the SIP interface between a RUE and the 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 relay user equipment. This is the traditional telecom term for an end-user customer, which in our case is a relay user.
Telecommunications relay services (TRS): Telephone transmission services that provide the ability for an individual who has a hearing impairment or speech impairment to engage in communication by wire or radio with a hearing individual in a manner that is functionally equivalent to the ability of an individual who does not have a hearing impairment or speech impairment to communicate using voice communication services by wire or radio. TRS includes services that enable two-way communication between an individual who uses a Telecommunications Device for the Deaf (TDD) or other non-voice terminal device and an individual who does not use such a device.
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.
Requirements LanguageThe keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in General Requirements
All HTTP/HTTPS connections specified throughout this document MUST use HTTPS. Both HTTPS and all SIP connections MUST use TLS conforming to at least and must support
All text data payloads not otherwise constrained by a specification in another standards document MUST be encoded as Unicode UTF/8.
SIP Signaling
Implementations of the RUE Interface MUST conform to the following core SIP standards (Base SIP) (Locating SIP Servers), (Offer/Answer), (User Agent Capabilities), (Outbound), (Session Description Protocol), (Privacy), (RTCP Attribute in SDP), (SIP Events), (UPDATE Method), (Loop-Fix), (Record Route fix), (ABNF fix), (Early Media), and (Geolocation Header).
In the above documents the RUE device conforms to the requirements of a SIP user Agent, and the provider conforms to the requirements of Registrar and Proxy Server where the document specifies different behavior for different roles. The only requirement on providers for RFC6655 (Events) is support for the Message Waiting Indicator (See Section ), which is optional and providers not supporting MWI need not support RFC6665.
In addition, implementation MUST conform to (Path), (ICE), (Reason header), (REFER Method), (Replaces Header), (Referred-By).
Implementations MUST include a "User-Agent" header field uniquely identifying the RUE application, platform, and version in all SIP requests, and MUST include a "Server" header field with the same content in SIP responses.
Registration
The RUE MUST register with a SIP registrar, following and at a provider it has an account with. If the configuration (please refer to Section 11) contains multiple "outbound-proxies", then the RUE MUST use them as specified in [RFC5626] to establish multiple flows.
The request-URI for the REGISTER request MUST contain the "provider-domain" from the configuration. The To-URI and From-URI MUST be identical URIs, formatted as specified in Section 13, using the "phone-number" and "provider-domain" from the configuration.
The RUE determines the URI to resolve by initially determining if an outbound proxy is configured. If it is, the URI will be that of the outbound proxy. If no outbound proxy is configured, the URI will be the Request-URI from the REGISTER request. The RUE extracts the domain from that URI and consults the DNS record for that domain. The DNS entry MUST contain NAPTR records conforming to RFC3263. One of those NAPTR records MUST specify TLS as the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.red.example.netv" could return:
If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MUST re-attempt registration without using the outbound mechanism.
The registrar MAY authenticate using SIP MD5 digest authentication. The credentials to be used (username and password) MUST be supplied within the credentials
section of the configuration and identified by the realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as
that used for other purposes, such as retrieving the RUE configuration or logging into the Provider's customer service portal. Because MD5 is considered
insecure, SHOULD be implemented by all implementations and SHA-based digest algorithms SHOULD be used for digest authentication.
If the registration request fails with an indication that credentials from the configuration are invalid,
then the RUE SHOULD retrieve a fresh version of the configuration.
If credentials from a freshly retrieved configuration are found to be invalid,
then the RUE MUST cease attempts to register and SHOULD inform the RUE User of the problem.
Support for multiple simultaneous registrations is OPTIONAL.
Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI SHOULD be permitted by the Provider. The Provider MAY limit the total number of simultaneous registrations. When a new registration request is received that results in exceeding the limit on simultaneous registrations, the Provider MAY then prematurely terminate another registration; however, it SHOULD NOT do this if it would disconnect an active call.
If a Provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it SHOULD take some action to prevent the affected RUE from automatically re-registering and re-triggering the condition.
Session EstablishmentNormal Call Origination
After initial SIP registration, the RUE adheres to SIP basic call flows, as documented in .
A RUE device MUST routes all outbound calls through an outbound proxy if configured.
INVITE requests used to initiate calls SHOULD NOT contain Route headers. Route headers MAY be included in one-stage dial-around calls and emergency calls. The SIP URIs in the To field and the Request-URI MUST be formatted as specified in subsection 6.4 using the destination phone number. The domain field of the URIs SHOULD be the "provider-domain" from the configuration (e.g., sip:+13115552368@red.example.com;user=phone). The same exceptions apply, including anonymous calls.
Anonymous calls MUST be supported by all implementations. An anonymous call is signaled per .
The From-URI MUST be formatted as specified in , using the phone-number and "provider-domain" from the configuration. It SHOULD also contain the display-name from the configuration when present. (Please refer to .)
Negotiated media MUST follow the guidelines specified in of this document.
To allow time to timeout an unanswered call and direct it to a videomail server, the User Agent Client MUST NOT impose a time limit less than the default SIP Invite transaction timeout of 3 minutes.
One-Stage Dial-Around Origination
Outbound dial-around calls allow a RUE user to select any Provider to provide interpreting services for any call.
"Two-stage" dial-around calls involve the RUE calling a telephone number that reaches the dial-around Provider and
using signing or DTMF to provide the called party telephone number. In two-stage dial-around, the To URI is the URI of
the dial-around Provider and the domain of the URI is the Provider domain from the configuration.
One-stage dial-around is a method where the called party telephone number is provided in the To URI and the Request-URI,
using the domain of the dial-around Provider.
For one-stage dial-around, the RUE MUST follow the procedures in with the
following exception: the domain part of the SIP URIs in the To field and the Request-URI MUST be the domain of the
dial-around Provider, discovered according to .
The following is a partial example of a one-stage dial-around call from VRS user +1-555-222-0001 hosted by red.example.com
to a hearing user +1-555-123-4567 using dial-around to green.example.com for the relay service. Only important details of the
messages are shown and many header fields have been omitted:
RUE Contact Information
To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK accepting a call by a RUE,
identifies the owner by sending a Call-Info header with a purpose parameter of "rue-owner".
The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is defined by to locate
message body parts. This URI type is present in a SIP message to convey the RUE ownership information as a
MIME body. The form of the RUE ownership information is a jCard . Please refer to
for an example of using Content-Indirect URLs in SIP messages. Note that use of the Content-Indirect URL
usually implies multiple message bodies ("mime/multipart").
Incoming Calls
The RUE MUST accept inbound calls sent to it by the proxy mentioned in the configuration.
If Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI exist,
the Provider MUST parallel fork the call to all registered RUEs so that they ring at the same time.
The first RUE to reply with a 200 OK answers the call and the Provider MUST CANCEL other call branches.
Emergency Calls
Implementations MUST conform to for handling of emergency calls, except that if the device is unable to determine its own location, it MAY send the emergency call without a Geolocation header and without a Route header (since it would be unable to query the LoST server for a route per RFC6881). If an emergency call arrives at the provider without a Geolocation header, the provider MUST supply location by adding the Geolocation header, and MUST supply the route by querying the LoST server with that location.
If the emergency call is to be handled using existing country specific procedures,
the Provider is responsible for modifying the INVITE to conform to the country-specific requirements.
In this case, location MAY be extracted from the RFC6881 conformant INVITE and used to
propagate it to the appropriate country-specific entities. Because the RUE may
have a more accurate and timely location of the device than the a manual entry
location for nomadic RUE devices, but country-specific procedures require the location to be pre-loaded in some entity prior to placing an emergency call, implementations of a RUE device MAY send a Geolocation header containing its
location in the REGISTER request if the configuration specifies it. That information MAY be used to populate the location to appropriate country-specific entities.
Implementations MUST implement Additional Data, . RUE devices MUST implement Data Provider, Device Implementation and Owner/Subscriber Information blocks. Providers MUST implement Data Provider and Service Information blocks as the call is forwarded to the PSAP.Mid Call Signaling
Implementations MUST support re-INVITE to renegotiate media session parameters (among other uses). Per , implementations MUST, be able to support an INFO request for full frame refresh for devices that do not support RTCP mechanisms (please refer to ). Implementations MUST support an in-dialog REFER ( updated by and including support for norefersub per ) with the Replaces header to enable call transfer.
URI Representation of Phone Numbers
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE MUST be represented as follows, depending on whether they can be represented as an E.164 number.
A dial string that can be written as an E.164 formatted phone number MUST be represented as a SIP URI with a URI ";user=phone" tag. The user part of the URI MUST be in conformance with 'global-number' defined in . The user part MUST NOT contain any 'visual-separator' characters.
Dial strings that cannot be written as E.164 numbers MUST be represented as dialstring URIs, as specified by , e.g., sip:411@red.example.net;user=dialstring.
The domain part of Relay Service URIs and User Address of Records (AoR) MUST (using resolve (in accord with ) to globally routable IPv4 addresses. The AoRs MAY also resolve to IPv6 addresses.
Transport
Implementations MUST conform to except that that this specification does not use the WebRTC data channel. See Section for how RUE supports real time text without the data channel.
Implementations MUST support SIP outbound (please also refer to ).
MediaThis specification adopts the media specifications for WebRTC ().
Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SIP call.
The RTP, RTCP, SDP and specific media requirements specified for WebRTC are adopted for this document. The RUE is a
WebRTC non-browser" endpoint, except as noted expressly below. The following sections specify the WebRTC documents to which conformance is required. "Mandatory to Implement" means a conforming implementation must implement the
specified capability. It does not mean that the capability must be used in every session. For example, OPUS is a mandatory to implement audio codec, and all conforming
implementations must support OPUS. However, implementation presenting a call across the RUE Interface where the call originates in the Public Switched Telephone Network, or an older, non-RUE-compatible device, which only offers G.711 audio, does not need to
include the OPUS codec in the offer, since it cannot be used with that call.SRTP and SRTCP
Implementations MUST support except that MediaStreamTracks are not used. Implementations MUST conform to Section 6.4 of .
Text-Based Communication
Implementations MUST support real-time text ( and ) via T.140 media.
One original and two redundant generations MUST be transmitted and supported, with a 300 ms transmission interval. Note that this is
not how real time text is transmitted in WebRTC and some form of transcoder would be required to interwork real time text in the data channel
of WebRTC to RFC4103 real time text.
Video
Implementations MUST conform to with the exception that, since backwards compatibility is desirable and older devices do not support VP8, that only H.264,
as specified in is Mandatory to Implement and VPB support is OPTIONAL at both the device and providers.
Audio
Implementations MUST conform to .
DTMF Digits
Implementations MUST support the "audio/telephone-event" media type. They MUST support
conveying event codes 0 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. Handling of other tones is OPTIONAL.
Session Description Protocol
The SDP offers and answers MUST conform except that the RUE Interface uses SIP transport for SDP.
Privacy
The RUE MUST be able to control privacy of the user by implementing a one-way mute of audio and or video, without signaling,
locally, but MUST maintain any NAT bindings by periodically sending media packets on all active media sessions containing
silence/comfort noise/black screen/etc. per .
Negative Acknowledgment, Packet Loss Indicator, and Full Intraframe Request Features
NACK SHOULD be used when negotiated and conditions warrant its use.
Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be preferred, as described in .
FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per RFC5104 subsection 4.3.1.2.
For backwards compatibility with calling devices that do not support the foregoing methods, implementations MUST implement SIP INFO messages to send and receive XML encoded Picture Fast Update messages according to .
ContactsCardDAV Login and Synchronization
Support of CardDAV by Providers is OPTIONAL.
The RUE MUST and Providers MAY be able to synchronize the user's contact directory between the RUE endpoint and one maintained
by the user's VRS provider using CardDAV ( and ).
The configuration MAY supply a username and domain identifying a CardDAV server and address book for this account.
To access the CardDAV server and address book, the RUE MUST follow Section 6 of RFC6764, using the chosen username and domain in place of an email address. If the request triggers a challenge for digest authentication credentials, the RUE MUST attempt to continue using matching "credentials" from the configuration. If no matching credentials are configured, the RUE MUST use the SIP credentials from the configuration. If the SIP credentials fail, the RUE MUST query the user.
Synchronization using CardDAV MUST be a two-way synchronization service, with proper handling of asynchronous adds, changes, and deletes at either end of the transport channel.
Contacts Import/Export Service
Implementations MUST be able to export/import the list of contacts in jCard json format.
The RUE accesses this service via the "contacts" URI in the configuration. The URL MUST resolve to identify a web server resource that imports/exports contact lists for authorized users.
The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request. If the request triggers a challenge for digest authentication credentials, the RUE MUST attempt to continue using matching "credentials" from the configuration. If no credentials are configured, the RUE MUST query the user.
Mail Waiting Indicator (MWI)
Support of MWI by Providers is OPTIONAL
Implementations MUST support subscriptions to "message-summary" events to the URI specified in the configuration.
In notification bodies, videomail messages SHOULD be reported using "message-context-class multimedia-message" defined in .
Provisioning and Provider SelectionTo simplify how users interact with RUE devices, the RUE interface defines a provisioning mechanism which consist of files stored on server that are retrieved by the RUE device. Two files are supported: one provides a directory of providers so that a user interface that allows easy provider selection either for registering or for dial-around. The other file provides configuration data for the device. The RUE device would retrieve these files at boot time. No mechanism for creating the files are specified. Each of the files contains a single json object. The retrieval mechanism is HTTPS download of that object from a provisioned location.RUE Provider Selection
To allow the user to select a relay service, the RUE MAY obtain, on startup, a list of Providers from a configured accessible URL. This file is MAY be a single file per country, containing all the providers authorized in that country, but MAY be any collection of providers.
The provider list, formatted as JSON, contains:
Version: Specifies the version number of the Provider list format. A new version number SHOULD only be used if the new version is not backwards-compatible with the older version. A new version number is not needed if new elements are optional and can be ignored by older implementations.
Providers: An array where each entry describes one Provider. Each entry consists of the following items:
name: This parameter contains the text label identifying the Provider and is meant to be displayed to the human VRS user.
domain: The domain parameter is used for configuration purposes by the RUE (as discussed in ) and as the domain to use when targeting one-stage dial-around calls to this Provider (as discussed in ).
operator: (OPTIONAL) The operator parameter is a SIP URL that identifies the operator "front-door" that VRS users may contact for manual (two-stage) dial-around calls.
The VRS user interacts with the RUE to select from the Provider list one or more Providers with whom the user has already established an account.RUE Configuration Service
A RUE device may retrieve a configuration from a provisioned URL using HTTPs.
The data returned will include a set of key/value configuration parameters to be used by the RUE,
formatted as a single JSON object and identified by the associated "application/json" MIME type,
to allow for other formats in the future.
The configuration data payload includes the following data items. Items not noted as (OPTIONAL) are REQUIRED. If other unexpected items are found, they MUST be ignored.
version: Identifies the version of the configuration data format. A new version number SHOULD only be used if the new version is not backwards-compatible with the older version. A new version number is not needed if new elements are optional and can be ignored by older implementations.
lifetime: Specifies how long (in seconds) the RUE MAY cache the configuration values. Values may not be valid when lifetime expires. Emergency Calls MUST continue to work.
display-name: (OPTIONAL) A user-friendly name to identify the subscriber when originating calls.
phone-number: The telephone number (in E.164 format) assigned to this subscriber. This becomes the user portion of the SIP URI identifying the subscriber.
provider-domain: The DNS domain name of the default Provider servicing this subscriber.
outbound-proxies: (OPTIONAL) A URI of a SIP proxy to be used when sending requests to the Provider.
mwi: (OPTIONAL) A URI identifying a SIP event server that generates "message-summary" events for this subscriber.
videomail: (OPTIONAL) A SIP URI that can be called to retrieve videomail messages.
contacts: An HTTPS URI that may be used to export (retrieve) the subscriber's complete contact list managed by the Provider.
carddav: (OPTIONAL) A username and domain name (separated by ""@"") identifying a "CardDAV" server and user name that can be used to synchronize the RUE's contact list with the contact list managed by the Provider.
sendLocationWithRegistration: True if the RUE should send a Geolocation Header with REGISTER, false if it should not. Defaults to false if not present.
ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN servers available for use by the RUE for establishing media streams in calls via the Provider.
credentials: (OPTIONAL) TBD
The wire format of the data is in keeping with the standard JSON description in RFC7159.
The "lifetime" parameter in the configuration indicates how long the RUE MAY cache the configuration values. If the RUE caches configuration values, it MUST cryptographically protect them. The RUE SHOULD retrieve a fresh copy of the configuration before the lifetime expires or as soon as possible after it expires. The lifetime is not guaranteed: the configuration may change before the lifetime value expires. In that case, the Provider MAY indicate this by generating authorization challenges to requests and/or prematurely terminating a registration.
Note: In some cases, the RUE may successfully retrieve a fresh copy of the configuration using
digest credentials cached from the prior retrieval. If this is not successful,
then the RUE will need to ask the user for the username and password.
Unfortunately, this authentication step might occur when the user is not present,
preventing SIP registration and thus incoming calls. To avoid this situation,
the RUE MAY retrieve a new copy of the configuration when it knows the user is present,
even if there is time before the lifetime expires.
Schemas
The following JSON schemas are for the Provider List and the RUE Configuration.
The following illustrates the message flow for retrieving a RUE automatic configuration using HTTPS Digest Authentication:AcknowledgementsBrett Henderson and Jim Malloy provided many helpful edits to prior versions of this document.IANA ConsiderationsThis memo includes no request to IANA.Security Considerations
The RUE is required to communicate with servers on public IP addresses and specific ports to perform its required functions. If it is necessary for the RUE to function on a corporate or other network that operates a default-deny firewall between the RUE and these services, the user must arrange with their network manager for passage of traffic through such a firewall in accordance with the protocols and associated SRV records as exposed by the Provider. Because VRS providers may use different ports for different services, these port numbers may differ from Provider to Provider.
Normative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]Session Initiation Protocol (SIP): Locating SIP ServersThe Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK]An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]A Privacy Mechanism for the Session Initiation Protocol (SIP)Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.SIP-Specific Event NotificationThis document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]The Session Initiation Protocol (SIP) UPDATE MethodAddressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking ProxiesThis document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]Addressing Record-Route Issues in the Session Initiation Protocol (SIP)A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.Location Conveyance for the Session Initiation ProtocolThis document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent ContactsInteractive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer ProtocolsThis document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]The Reason Header Field for the Session Initiation Protocol (SIP)The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]The Session Initiation Protocol (SIP) Refer MethodThis document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]Suppression of Session Initiation Protocol (SIP) REFER Method Implicit SubscriptionThe Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]Clarifications for the Use of REFER with RFC 6665The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.The Session Initiation Protocol (SIP) "Replaces" HeaderThis document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS-TRACK]The Session Initiation Protocol (SIP) Referred-By MechanismThe Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]Session Initiation Protocol (SIP) Basic Call Flow ExamplesThis document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.Content-ID and Message-ID Uniform Resource LocatorsThe Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]The tel URI for Telephone NumbersThis document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]Dial String Parameter for the Session Initiation Protocol Uniform Resource IdentifierRFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]Registration of the text/red MIME Sub-TypeThis document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]RTP Payload for Text ConversationThis memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]RTP Payload for DTMF Digits, Telephony Tones, and Telephony SignalsThis memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) FlowsThis document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]XML Schema for Media ControlThis document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. This memo provides information for the Internet community.CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.jCard: The JSON Format for vCardThis specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]Message Context for Internet MailThis memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]The JavaScript Object Notation (JSON) Data Interchange FormatJavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.Best Current Practice for Communications Services in Support of Emergency CallingThe IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.Additional Data Related to an Emergency CallWhen an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.Overview: Real Time Protocols for Browser-based ApplicationsThis document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group.Web Real-Time Communication (WebRTC): Media Transport and Use of RTPThe Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported.JavaScript Session Establishment ProtocolThis document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols.WebRTC Audio Codec and Processing RequirementsThis document outlines the audio codec and processing requirements for WebRTC endpoints.WebRTC Video Processing and Codec RequirementsThis specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.Transports for WebRTCThis document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes.WebRTC Security ArchitectureThis document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web".The Session Initiation Protocol (SIP) Digest Authentication SchemeThis document updates the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for SHA2 digest algorithms to replace the MD5 algorithm.VRS US Providers Profile TWG-6-1.0SIPForum