DISPATCH | P. Kyzivat, Ed. |
Internet-Draft | |
Intended status: Informational | H. Schulzrinne, Ed. |
Expires: January 21, 2017 | FCC |
July 20, 2016 |
Interoperability Profile for Relay User Equipment (RUE)
draft-vrs-rue-dispatch-00
This document defines and specifies a protocol profile defining an interface between a relay service endpoint used by a deaf or hard-of-hearing user and a relay service.
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 http://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 January 21, 2017.
Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Video 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 Relay User Equipment (RUE) profile is a profile of the Session Initiation Protocol (SIP) and related media protocols which enables end-user equipment registration and calling for video relay service (VRS) calls. It specifies the minimal set of call flows, 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.
This RUE profile supports the requirements of relay services in the United States, as described in 47 CFR 64.601 et seq., but may be applicable to similar uses elsewhere.
This document defines a standard interface between a RUE and the services offered by relay service (RS) providers. This document does not enumerate the features that the RUE or relay service provider must support to meet, for example, national regulatory requirements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
In many portions of this document, the document specifies a required implementation for an optional feature; i.e., that a provider's systems MAY implement a specific feature, and if they do, they MUST implement it in a specific way, in order to implement the functionality provided through this document.
All HTTP/HTTPS connections specified throughout this document MUST use HTTPS, and MUST use TLS 1.2 [RFC5246] or later, using a server-side certificate.
During the establishment of a TLS connection with a provider the RUE MAY be asked by the server for a client certificate. In that case it SHOULD provide a client certificate. Providers MAY reject requests that fail to provide a recognized certificate.
RUEs 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.
All text data payloads not otherwise constrained by a specification in another standards document MUST be encoded as Unicode UTF/8.
In order to allow the user to select a relay service, the RUE SHALL obtain, on startup, a list of providers from a publicly accessible URL, e.g., hosted by the national regulatory agency. This provider will be used for outbound calls; the provider chosen for inbound calls is determined by the user's' E.164 number.
The provider list, formatted as JSON, contains:
The VRS user interacts with the RUE to select from the provider list one or more providers with which the user has already established an account.
{ "version": 1, "providers": [ { "name": "Red", "domain": "red.example.net", "operator": "sip:operator@red.example.net" }, { "name": "Green", "domain": "green.example.net", "operator": "sip:+18885550123@green.example.net;user=phone" }, { "name": "Blue", "domain": "blue.example.net" } ] }
Figure 1: Example of a provider list
The RUE uses the following steps to obtain the configuration for each selected provider:
This document extends [RFC6011] by describing a format for the configuration data.
The data returned will include a set of key/value configuration parameters to be used by the RUE, formatted as a JSON object and identified by the associated [RFC7159] "application/json" MIME type to allow for other formats in the future.
(As specified in section 2.3.2.1 of [RFC6011] the query for the configuration includes parameters that identify the RUE. The provider's configuration service MAY use these parameters to select distinct configurations for each RUE the user uses.)
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.
Below is an example configuration payload.
NOTE: For document formatting reasons long quoted strings have been broken into multiple quoted strings separated by whitespace. This is solely for publication reasons - it is not valid JSON syntax.
{ "version": 1, "lifetime": 86400, "display-name" : "Bob Smith", "phone-number": "+18135551212", "provider-domain": "red.example.net", "outbound-proxies": [ "sip:p1.red.example.net", "sip:p2.red.example.net" ], "mwi": "sip:+18135551212@red.example.net", "videomail": "sip:+18135551212@vm.red.example.net", "contacts": "https://red.example.net:443/contacts" "/export/xcard" , "carddav": "bob@red.example.com" , "ice-servers": [ "uri": "stun:stun.l.google.com:19302", "uri": "turn:turn.red.example.net:3478" ], "credentials": [ { "realm": "red.example.net", "username": "bob", "password": "reg-pw" }, { "realm": "proxies.red.example.net", "username": "bob", "password": "proxy-pw" }, { "realm": "cd.red.example.net", "username": "bob", "password": "cd-pw" }, { "realm": "vm.red.example.net", "username": "bob", "password": "vm-pw" }, { "realm": "stun-turn.red.example.net", "username": "bob", "password": "stun-turn-pw" } ] }
Figure 2: Example RUE configuration JSON object
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, but MUST do so in a cryptographically protected way. The RUE SHOULD retrieve a fresh copy of the configuration before the lifetime expires, or as soon as possible after it expires. However 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 retrieval of a fresh copy of the configuration may be successfully accomplished using digest credentials cached from the prior retrieval. If this is not the case, then it will be necessary to interact with the user to ask her for the user name 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 want to retrieve a new copy of the configuration when it knows the user is present, even when there is still plenty of time before the lifetime expires.
Below are JSON schemas for the Provider List and the RUE Configuration. These are represented using the JSON Content Rules [JCR] schema notation.
{ "version": 1, "providers": [ 1* { "name": string, "domain": fqdn, ?"operator": ; "front-door" access to provider uri, ; (sip uri) * /^.*$/ : any ; (allow future extensions) } ] , * /^.*$/ : any ; (allow future extensions) }
Figure 3: Provider list JSON schema
{ "version": 1, ; Interface version "lifetime": integer, ; Deadline (in seconds) for ; refreshing this config without ; user input. "phone-number": /^\+[0-9]+$/ , ; E.164 phone number ; for this user ?"display-name" : string,; display name for From: header "provider-domain": fqdn, ; SHOULD match that in Provider List ?"outbound-proxies": [ 1* : uri ], ; sip URIs ?"mwi": uri , ; sip URI for MWI subscriptions ?"videomail": uri , ; sip URI for videomail retrieval "contacts": uri , ; https URI for contact list retrieval ?"carddav": /^[^@]+@[^@]+$/ , ; for contact list synch ?"ice-servers": ; (Required for ICE use) [ 1* : uri ], ; (stun[s] & turn[s] URIs ?"credentials": ; for digest authentication [ 1* { "realm": string, "username": string, "password": string } ], * /^.*$/ : any ; (allow future extensions) }
Figure 4: RUE configuration JSON schema
Figure 5 illustrates the message flow for retrieving a configuration.
,-. `-' /|\ ,---. ,---. ,------------. ,----------------. ,---. | |RUE| |DNS| |HTTPS Server| | Provider | |CRM| / \ | | | | | | |Global Settings | | | RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' | | | | | | [1] Select a VRS Provider name | | | | ------->| | | | | | | | | | | [2] NAPTR "SFUA.CFG" red.example.net | | | |----->| | | | | | | | | | [3] NAPTR "!.*!https://server.red.example.net/!" | | | |<-----| | | | | | | | | | [4] If NAPTR found, query DNS server.red.example.net | | |----->| | | | | | | | | | [5] If NXDOMAIN, query DNS config.red.example.net | | | | - - >| | | | | | | | | | [6] IP Address of Config Server | | | | |<-----| | | | | | | | | | [7] Establish TLS connection | | | | |<--------------->| | | | | | | | | [8] HTTP: https://config.red.example.net/v1 | | | |---------------->| | | | | | | | | [9] HTTP: 401 Unauthorized | | | WWW-Authenticate Digest realm="Y" qop="auth,auth-int" nonce=| | |<----------------| | | | | | | | | [10] Query for userid/pw | | | |<--------| | | | | | | | | | | [11] User="bob", pw="bob's global provider pw" | | |-------->| | | | | | | | | | | [12] HTTP: https://config.red.example.net/v1 | | | Authorization Digest username="bob" realm="Y" qop="auth" | | nonce=... response="..." ... | | | |---------------->| | | | | | | | | | [13] Find subscriber information for username="bob" | | | | |----------------------------->| | | | | | | | [14] Subscriber specific configuration information | | | | |<-----------------------------| | | | | | | | [15] Retrieve provider specific settings | | | | |---------------->| | | | | | | | | [16] Provider configuration information | | | | | |<----------------| | | | | | | | [17] 200 OK + JSON merge subscriber + provider configs | | |<----------------| | | | | | | | | RUE User ,---. ,---. ,------------. ,----------------. ,---. ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| `-' | | | | | | |Global Settings | | | /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' | / \
Figure 5: Diagram of RUE automatic configuration using HTTPS Digest authentication
The RUE MUST register with a SIP registrar, following [RFC3261] and [RFC5626] and MUST use SIP-over-TLS. If the configuration 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 URI to be resolved by the RUE for sending the REGISTER request (from outbound-proxies if present, else the request-URI) MUST have a domain that is provisioned in DNS with NAPTR records that specify TLS as the preferred transport for SIP. For example a DNS NAPTR query for sip:p1.red.example.net could return:
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.p1.red.example.net.
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 MUST authenticate using SIP MD5 digest authentication. The credentials to be used (username and password) MUST be supplied within the credentials section of the configuration, 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.
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.
Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI SHALL be permitted by the VRS 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 when it would cause an active call to be disconnected.
If a provider prematurely terminates a registration in order 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. For example, it could change the registration username/password and revoke cached authorization data so that further attempts by this RUE (or all RUEs) to register with this URI will require the end user of the RUE to re-login before it can fetch a configuration containing the new userid/password.
,-+-. ,-+-. ,------+------. |RUE| |DNS| |SIP Registrar| `-+-' `-+-' `------+------' | | | [1] Look up SRV DNS for _sip._tls.red.example.net |------>| | | | | [2] SRV DNS response with red.example.net:5061 |<------| | | | | [3] Look up DNS A/CNAME for red.example.net |------>| | | | | [4] IP Address(es) of SIP REGISTRAR Server(s) |<------| | | | | [5] Establish TLS connection to registrar |<----------------->| | | | [6] SIP: REGISTER sip:red.example.net To: sip:+18135551212@red.example.net;... From: sip:+18135551212@red.example.net;... |------------------>| | | | [7] SIP: 401 Unauthorized WWW-Authenticate Digest realm="read.example.net" | qop="auth,auth-int" nonce=... |<------------------| | | | [8] SIP: REGISTER sip_username@sip_domain Authorization Digest username="bob" realm="red.example.net" | qop="auth" nonce=... response="..." |------------------>| | | | [9] 200 OK | | |<------------------| | | | ,-+-. ,-+-. ,------+------. |RUE| |DNS| |SIP Registrar| `---' `---' `-------------'
Figure 6: RUE SIP registration message flow
The RUE SHALL support ICE [RFC5245] and SHALL be able to use STUN [RFC5389] and TURN [RFC5766] servers, when provided, to generate ICE candidates. If a STUN or TURN server issues a challenge for digest credentials, the RUE MUST attempt to continue using matching credentials from the configuration.
Providers MAY operate STUN and TURN servers for RUEs to use (see Section 6.2 for configuration). Alternatively, providers MAY use media relaying for all relay and point-to-point calls.
The RUE MUST support SIP outbound [RFC5626] (also see Section 7).
A RUE MUST be able to synchronize the user's contact directory between the RUE endpoint and one maintained by the user's VRS provider using CardDAV ([RFC6352] and [RFC6764]).
Support of CardDAV by providers is OPTIONAL.
The provider MAY include a carddav item in the configuration to supply a username and domain identifying a CardDAV server and address book for this account. If no carddav item is present, the RUE SHOULD use the phone-number and provider-domain.
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 MAY query the user.
Synchronization using CardDAV SHALL be a two-way synchronization service, properly handling asynchronous adds, changes, and deletes at either end of the transport channel.
Figure 7 shows an example message flow for CardDAV synchronization.
,-. `-' /|\ | ,---. ,---. ,---------------. ,---. / \ |RUE| |DNS| |CardDAV Service| |CRM| RUE User `-+-' `-+-' `-------+-------' `-+-' | | | | | [1] Select a VRS Provider name | | | ------->| | | | | | | | | [2] Lookup SRV _carddavs._tcp.red.example.net | | |------>| | | | | | | | [3] | SRV carddav.red.example.net:443 | | |<------| | | | | | | | [4] resolve carddav.red.example.net | | | |------>| | | | | | | | [5] IP Address of CardDAV Server | | |<------| | | | | | | | [6] Establish TLS connection to carddav.red.example.net:443 | |<------------------>| | | | | | | [7] HTTP: (CardDAV request) | | | |------------------->| | | | | | | [8] HTTP: 401 Unauthorized | | WWW-Authenticate Digest | | realm="cd.red.example.net" | | qop="auth,auth-int" nonce=... | | | |<-------------------| | | | | | | [9] HTTP: (CardDAV request) | | Authorization Digest username="bob" | realm="cd.red.example.net" qop="auth" | nonce=... response="..." | | | |------------------->| | | | | | | | | [10] Sync address book | | |<..................>|<..........>| | | | | | RUE User ,-+-. ,-+-. ,-------+-------. ,-+-. ,-. |RUE| |DNS| |CardDAV Service| |CRM| `-' `---' `---' `---------------' `---' /|\ | / \
Figure 7: RUE CardDAV message flow
Each provider MUST provide a standard xCard export interface, and RUEs MUST be able to import the list of contacts in xCard [RFC6351] XML format.
The provider MUST supply a URI for access to this service via the contacts URI in the configuration. The URL MUST resolve to identify a web server resource that exports contact lists for authorized user.
The RUE MAY retrieve the contact list (address book) by issuing an HTTPS 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 MAY query the user.
Figure 8 shows an example message flow for contact list retrieval.
,-. `-' /|\ | ,---. ,---. ,---------------------------. ,---. / \ |RUE| |DNS| |Contacts Export Web Service| |CRM| RUE User `-+-' `-+-' `-------------+-------------' `-+-' | | | | | [1] Select a VRS Provider name | | | ------->| | | | | | | | | [2] resolve red.example.net | | | |------>| | | | | | | | [3] IP Address of Web Server | | | |<------| | | | | | | | [4] Establish TLS web connection to red.example.net | | |<------------------------>| | | | | | | [5] HTTP: GET /contacts/export/xcard | | | |------------------------->| | | | | | | [6] HTTP: 401 Unauthorized | | WWW-Authenticate Digest | | realm="cd.red.example.net" | | qop="auth,auth-int" nonce=... | | | |<-------------------------| | | | | | | [7] HTTP: GET /contacts/export/xcard | | Authorization Digest username="bob" | | realm="cd.red.example.net" qop="auth" | | nonce=... response="..." | | | |------------------------->| | | | | | | | | [8] Find contacts for username="bob" | | | | |----------------->| | | | | | | | [9] Contacts list in xCard format | | | (application/vcard+xml) | | | | |<-----------------| | | | | | | | [10] 200 OK | | | |<-------------------------| | | | | | | RUE User ,-+-. ,-+-. ,-------------+-------------. ,-+-. ,-. |RUE| |DNS| |Contacts Export Web Service| |CRM| `-' `---' `---' `---------------------------' `---' /|\ | / \
Figure 8: Message flow for RUE contacts retrieval using xCard
After initial SIP registration, the RUE adheres to SIP [RFC3261] basic call flows, as documented in [RFC3665].
The RUE SHALL route all calls through the outbound proxy of the default provider. INVITE requests used to initiate calls SHOULD NOT contain route headers except that one route header which addresses the outbound proxy MAY be added. The SIP URIs in the To field and the Request-URI MUST be formatted as specified in Section 13 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 From-URI MUST be formatted as specified in Section 13, using the phone-number and provider-domain from the configuration. It SHOULD also contain the display-name from the configuration, when present. (See Section 6.2.)
Negotiated media MUST follow the guidelines specified in Section 14 of this document.
Only relay calls use dial around. If the dialed number is in the iTRS RND, the call is a point-to-point call and follows the procedures in Section 11.1.
For one-stage dial-around the RUE MUST follow the procedures in Section 11.1 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 Section 6.1.
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| |Default | |Dial-Around| | | |Provider | | Provider | `-+-' `----+----' `-----+-----' | | | | [1] INVITE | | |-------------->| [2] INVITE | | |-------------->| Message Details: [1] INVITE Rue -> Default Provider INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 To: <sip:+15551234567@green.example.net;user=phone> From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone> Route: sip:green.example.net [2] INVITE Default Provider -> Dial-Around Provider INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 To: <sip:+15551234567@green.example.net;user=phone> From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone>
Figure 9: Example of one-stage dial around call
After initial SIP registration, the RUE SHALL be reachable via their telephone number.
As per SIP [RFC3261] basic call flows, as shown in [RFC3665], in-bound SIP INVITEs SHALL be forwarded to the SIP-registered RUE.
All SIP registered RUE with the same SIP URI should receive the same parallel forked SIP INVITE so that they ring at the same time. The first RUE to reply with a 200 OK answers the call, and the other call branches should be CANCELed.
If no RUE has an active SIP registration or none of the RUE respond to the call during the ring period chosen by the provider, and a videomail service is available, the in-bound SIP INVITE SHALL be forwarded to the videomail service, as in, sip:+18135551212@vm.red.example.net.
RUEs MUST comply with [RFC6881] for handling of emergency calls, with the following exception:
Providers MAY comply with [RFC6881] for handling of emergency calls. In addition they MUST:
Other behavior not specified by [RFC6881] is specified by Section 11.
,-+-. ,----+----. |RUE| |Default | | | |Provider | `-+-' `----+----' | | | [1] INVITE | |-------------->| | | Message Details: [1] INVITE Rue -> Default Provider INVITE urn:service:sos SIP/2.0 Via: ... Max-Forwards: ... To: <urn:service:sos> From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone> Call-ID: ... Geolocation: <geo:40.6777,-111.915;u=0> Geolocation-Routing: yes Accept: application/sdp, application/pidf+xml CSeq: ... Contact: ... Content-Type: application/sdp Content-Length: ... ...Session Description Protocol (SDP) goes here
Figure 10: Example of emergency call set-up with geo URI
If the provider includes an MWI URI in the configuration (see Section 6.2) then it MUST process a subscription to message-summary events [RFC3842] at that URI.
To subscribe to MWI the RUE SHOULD attempt to subscribe to message-summary events at the URI provided by configuration. If there is no URI in the configuration the RUE SHOULD NOT attempt to subscribe to message-summary events. (This differs from the default behavior implied in [RFC3842].)
In notification bodies videomail messages SHOULD be reported using message-context-class multimedia-message, defined in [RFC3458].
To retrieve videomail, the RUE establishes a SIP session to the videomail URI in the configuration. (See Section 6.2.) The user interaction required to select messages to view is at the discretion of the provider; the provider MAY also offer other means, such as a web page, to view video mail.
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 [RFC3966]. The user part MUST NOT contain any 'visual-separator' characters. The 'hostport' [RFC3261] in the URI depends upon the provider's setup.
Dial strings that cannot be written as E.164 numbers MUST be represented as dialstring URIs, as specified by [RFC4967], e.g., SIP:411@red.example.net;user=dialstring
The RUE MUST support real-time text ([RFC4102],[RFC4103] and [RFC5194]) via T.140 media.
One original and two redundant generations SHALL be transmitted and supported, with a 300 ms transmission interval.
The RUE must implement the video/H.264 [RFC6184] Constrained Baseline Profile, Level 1.3, packetization mode 1.
Both RUEs and providers MUST support G.711 mu-law and they SHOULD support G.722. In addition, G.722.1 and/or G.722.2 MAY also be supported.
The RUE and providers MUST offer and accept offers of the "audio/telephone-event" [RFC4733] media type. They MUST support conveying event codes 0 through 15 (DTMF digits "0"-"9", "A"-"D","*","#") defined in Table 7 of [RFC4733]. Handling of other tones is OPTIONAL.
All media streams between the RUE and another endpoint or relay provider MUST be exchanged using the real-time transport protocol (RTP) as described in [RFC3550]. All RTP and RTCP traffic over UDP MUST use symmetric RTP [RFC4961]. Receivers of RTP traffic MUST be capable of processing RTP packets with a different packetization rate than the rate used for sending.
During a call, codec control messages SHOULD be used as described in [RFC5104] to negotiate maximum bitrate. Specifically, Temporary Maximum Media Stream Bit Rate Request (TMMBR) SHOULD be used where endpoints have detected the need to decrease or increase the bit rate. Where either side of a session doesn't support CCM TMMBR, INVITE messages MAY be used during a call to renegotiate the use of bandwidth. Automatic bit rate control SHALL be applied on video for the purpose of enabling transmission of at least 30 frames of video per second with low latency and good video quality.
Implementations SHOULD support the RTP/AVPF profile per [RFC4585] for RTCP feedback support, but MUST signal "RTP/AVP" in the SDP m-line for compatibility. Supporting the RTP/AVPF profile allows implementations to use advanced RTCP mechanisms, like indicating packet loss, requesting intra frame and temporary bitrate change indication, which are essential for video streams.
Supported AVPF messages MUST be declared by RTCP Feedback attributes. Since implementations convey media streams from RUEs of varying background, there may be situations when no AVPF attributes are supported in a session.
For complete support of both AVPF and AVP, it is recommended to make an initial INVITE with "AVPF". If some media are not accepted with that profile, then a re-INVITE should be made with AVP declaration on the non-accepted media and the other media unchanged.
For calls with more than two parties, negative acknowledgement mode (NACK) SHOULD be used. With only two parties, NACK MAY be used if the round-trip latency time is low enough to allow it.
Signaling picture lossses as Packet Loss Indicator (PLI) SHOULD be preferred, as described in [RFC5104].
FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per draft-ietf-avt-avpf-ccm-10 [draft-ietf-avt-avpf-ccm-10] section 4.3.1.2
If the above have not been negotiated because either side of the call cannot support it, SIP INFO messages MAY be used to send XML encoded Picture Fast Update messages according to [RFC5168].
This memo includes no request to IANA.
The RUE is required to communicate with a number of servers on public IP addresses and specific ports in order to perform its required functions. If it is necessary for a subscriber to operate the client software on a corporate or other network which operates a default-deny firewall between the RUE and these services, the user will have to 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 RS provider. Because the VRS providers may use different ports for different services, these port numbers may be different from provider to provider.
Contributions to this document have been made by:
Jay Ashworth, Grant Beckmann, Lorenzo Benoni, Ian Blenke, Scot Brooksby, Byron Caswell, Eugene Christensen, Brandon Dopf, Dennis Episkopos, Kadian Ferguson, Brendan Foley, James Hamlin, Dustin Laun, George Lee, John Martin, Bruce Mattie, Adam Montero, Andrew Mulitz, Tom Murillo, Jose Pereira, Peter Preinitz, Isaac Roach, Zarko Roganovic, Lydia Runnels, Steve Saunders, Ed Sayers, Jeremy Shaffner, Joshua Shaffner, Roger Slusser, Mike Strecker, Antonio Sweet, Kyle Vaught, Claudio Villalobos.
The completion of the document was facilitated by MITRE staff.
<vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0"> <vcard> <fn><text>Billy Boberson</text></fn> <n> <surname>Boberson</surname> <given>Billy</given> <additional/> <prefix/> <suffix>ing. jr</suffix> <suffix>M.Sc.</suffix> </n> <lang> <parameters><pref><integer>1</integer></pref></parameters> <language-tag>en</language-tag> </lang> <tel> <parameters> <type> <text>work</text> <text>voice</text> </type> </parameters> <uri>tel:+1-206-656-9254;ext=102</uri> </tel> <tel> <parameters> <type> <text>work</text> <text>voice</text> <text>cell</text> <text>video</text> </type> </parameters> <uri>tel:+1-253-262-6501</uri> </tel> </vcard> </vcards>
Figure 11: vCard example