Interoperability Profile for Relay User Equipment
Extracted elements (31)
This specification adopts WebRTC media specifications (RFC 8825 suite) as its media foundation, treating the RUE as equivalent to a browser-based WebRTC client with SIP signaling substituted for the WebRTC browser signaling. A gateway bridging WebRTC browser clients to the RUE interface is assumed but not specified, enabling browser-based VRS clients.
Implementations MUST conform to RFC 8835 (Transports for WebRTC) except for its guidance on the WebRTC data channel, which this specification does not use. Support for multiple simultaneous SIP registrations from different RUE devices sharing the same SIP URI SHOULD be permitted by the provider.
Real-time text is carried using RFC 4103 (RTP payload for T.140) over SIP rather than via the WebRTC data channel (RFC 8865). This diverges from the WebRTC norm; gateways bridging browser-based WebRTC clients to RUE must transcode between RFC 8865 data-channel text and RFC 4103 RTP text.
All HTTP/HTTPS and SIP connections MUST use HTTPS/TLS conforming to at least RFC 7525 and MUST support TLS 1.3 per RFC 8446. All text data payloads not otherwise constrained MUST be encoded as Unicode UTF-8.
Emergency call implementations MUST conform to RFC 6881. If the device cannot determine its location, it MAY send the emergency call without a Geolocation header field. 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. Implementations MUST implement additional data per RFC 7852 including data provider, device, and owner/subscriber information blocks.
Implementations intended to support mobile platforms MUST support RFC 8599 (Push Notification with SIP) and MUST use it as at least one way to support waking up the client from the background state.
Implementations MUST conform to RFC 7742 for video, with the following exception: only H.264 is Mandatory to Implement; VP8 support is OPTIONAL at both device and provider levels. VP8 is optional because backwards compatibility with older devices that do not support VP8 is desirable.
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.
Implementations MUST support IPv4 and IPv6. The same IP version MUST be used for both signaling and media of a call unless ICE (RFC 8445) is used, in which case candidates may explicitly offer IPv4, IPv6, or both.
Implementations MUST support real-time text via T.140 media per RFC 4102/4103, with one original and two redundant generations at a 300 ms transmission interval. Implementations MUST support RFC 9071 (RTP-Mixer Formatting of Multiparty Real-Time Text), especially for emergency calls.
Implementations MUST support SRTP and SRTCP per RFC 8834, conforming to Section 6.4 of RFC 8827 (WebRTC Security Architecture). MediaStreamTracks as defined in RFC 8834 are not used.
Implementations MUST support the 'audio/telephone-event' media type per RFC 4733 and MUST support conveying event codes 0 through 11 (DTMF digits '0'-'9', '*', '#'). Implementations MUST conform to RFC 7874 for audio codec requirements (WebRTC audio profile including Opus).
NACK, FIR, and PLI features per RFC 4585 and RFC 5104 MUST be implemented and MUST be announced with the 'ccm' feedback value. For backwards compatibility with devices not supporting these, implementations MUST also implement SIP INFO messages to send/receive XML-encoded Picture Fast Update messages per RFC 5168.
Providers and RUE devices MUST support both one-stage and two-stage dial-around. In one-stage dial-around, the domain part of the SIP URIs in the To field and Request-URI MUST be the domain of the dial-around provider.
RUE devices MUST support video mail retrieval via SIP call to a specified URI using DTMF and via a browser-based HTTPS interface. Implementations MUST support subscriptions to 'message-summary' events (RFC 3842); providers MUST support MWI if they support video mail, and RUE devices MUST support MWI.
RUE interface implementations MUST conform to a defined set of core SIP standards including RFC 3261, RFC 3263, RFC 3264, RFC 5626 (Outbound), RFC 8866 (SDP), RFC 8445/8839 (ICE), and RFC 6442 (Geolocation), among others. Implementations MUST implement full ICE, though they MAY interwork with ICE-lite user agents.
SIP URIs constructed from dial strings that can be expressed as E.164 numbers MUST use a SIP URI with ';user=phone' tag and the user part MUST conform to 'global-number' per RFC 3966 without any 'visual-separator' characters. Non-E.164 dial strings MUST use dialstring URIs per RFC 4967.
The 'instanceId' parameter provided to the RUE Configuration service MUST be the same value each time that instance (same implementation on same device) queries the interface. If cached configuration values are used, they MUST be cryptographically protected against unauthorized disclosure.
The RUE MUST only accept inbound calls from a proxy mentioned in the configuration. When multiple RUEs share the same SIP URI, the provider MUST parallel fork the incoming call to all registered RUEs, and MUST cancel other branches via CANCEL after the first 200 OK.
The RUE MUST provide user privacy by implementing local one-way mute (without signaling) for both audio and video. However, the RUE MUST maintain NAT bindings by periodically sending silence/comfort noise/blank screen media packets on all active media sessions per RFC 6263.
The RUE MUST register with a SIP registrar per RFC 3261 and RFC 5626. The Request-URI for REGISTER MUST contain the 'provider-domain' from configuration; To and From URIs MUST be identical. The DNS entry MUST contain NAPTR records per RFC 3263, and one MUST specify TLS as preferred transport. RFC 8760 MUST be supported and SHA-512 digest algorithms MUST be supported.
The SIP credentials used for registration (user-name/sip-password) SHOULD NOT be the same as those used for other purposes. If registration fails due to invalid credentials, the RUE MUST retrieve a fresh configuration; if freshly retrieved credentials are also invalid, the RUE MUST cease registration attempts and inform the user.
The configuration versioning mechanism uses a major/minor scheme where minor version increments indicate backwards-compatible changes and major version increments indicate breaking changes. Implementations MUST ignore any object members they do not recognize. Minor version definitions SHALL only add objects or optional members, never delete or change existing ones.
The initial INVITE for a call from a RUE, or the 200 OK used to accept a call, MUST include a Call-Info header field with purpose parameter 'rue-owner' identifying the RUE owner. The URI MAY be an HTTPS URI or Content-ID URL pointing to an xCard (RFC 6351) body containing the owner's name, address, phone number, and email.
The RUE Configuration service exposes two HTTPS endpoints: '/ProviderConfig' (unauthenticated, returns signup, dial-around, and help desk data) and '/RueConfig' (authenticated, returns per-subscriber configuration including phone-number, provider-domain, SIP credentials, ICE servers, MWI/videomail URIs, and CardDAV details). Both accept optional 'apiKey' and required 'instanceId' query parameters.
The RUE Provider Selection service returns a ProviderList JSON object containing an array of providers, each with a human-readable 'name' and a 'providerEntryPoint' string (starting with a domain). IANA maintains a registry mapping country codes to list entry point URIs from which the full provider list is obtained.
IANA created the 'RUE Provider List' registry with Expert Review policy. Each entry has two fields: a two-letter ISO 3166 country code and a list entry point string used to compose the URI to the provider list interface for that country.
IANA registered the new predefined value 'rue-owner' for the 'purpose' parameter of the SIP Call-Info header field in the 'Header Field Parameters and Parameter Values' subregistry of the SIP Parameters registry.
RUE implementations MUST include a user interaction step to select from available providers before proceeding to register with any provider, because different providers within a country may have different policies. This ensures informed provider selection rather than silent automatic registration.
The RUE must communicate with servers on public IP addresses and specific ports; VRS providers may use different ports for different services. Users on networks with default-deny firewalls must arrange with their network manager for appropriate traffic passage based on the protocols and SRV records exposed by their provider.
When a Communications Assistant participates in a relay call, the CA has access to the full conversation content even though the call is nominally between the two endpoints. Confidentiality of CA-handled conversations is governed by contractual or legal requirements.