draft-ietf-rum-rue-06.txt   draft-ietf-rum-rue-07.txt 
rum B. Rosen rum B. Rosen
Internet-Draft 29 July 2021 Internet-Draft 26 August 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 30 January 2022 Expires: 27 February 2022
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-06 draft-ietf-rum-rue-07
Abstract Abstract
Video Relay Service (VRS) is a term used to describe a method by Video Relay Service (VRS) is a term used to describe a method by
which a hearing persons can communicate with deaf/Hard of Hearing which a hearing persons can communicate with deaf/Hard of Hearing
user using an interpreter ("Communications Assistant") connected via user using an interpreter ("Communications Assistant") connected via
a videophone to the deaf/HoH user and an audio telephone call to the a videophone to the deaf/HoH user and an audio telephone call to the
hearing user. The CA interprets using sign language on the hearing user. The CA interprets using sign language on the
videophone link and voice on the telephone link. Often the videophone link and voice on the telephone link. Often the
interpreters may be supplied by a company or agency termed a interpreters may be supplied by a company or agency termed a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 January 2022. This Internet-Draft will expire on 27 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 6, line 19 skipping to change at page 6, line 19
conforming to at least [RFC7525] and must support [RFC8446] conforming to at least [RFC7525] and must support [RFC8446]
All text data payloads not otherwise constrained by a specification All text data payloads not otherwise constrained by a specification
in another standards document MUST be encoded as Unicode UTF/8. in another standards document MUST be encoded as Unicode UTF/8.
Implementations MUST support IPv4 and IPv6. Dual stack support is Implementations MUST support IPv4 and IPv6. Dual stack support is
NOT required and provider implementations MAY support separate NOT required and provider implementations MAY support separate
interfaces for IPv4 and IPv6 by having more than one server in the interfaces for IPv4 and IPv6 by having more than one server in the
appropriate SRV record where there is either an A or AAAA record in appropriate SRV record where there is either an A or AAAA record in
each server DNS record but not both. The same version of IP MUST be each server DNS record but not both. The same version of IP MUST be
used for both signaling and media of a call. used for both signaling and media of a call unless ICE ([RFC5245]) is
used, in which case candidates may explicitly offer IPv4, IPv6 or
both for any media stream.
5. SIP Signaling 5. SIP Signaling
Implementations of the RUE Interface MUST conform to the following Implementations of the RUE Interface MUST conform to the following
core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP
Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent
Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description
Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP),
[RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop- [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-
Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960]
skipping to change at page 10, line 38 skipping to change at page 10, line 38
Figure 1 Figure 1
5.2.3. RUE Contact Information 5.2.3. RUE Contact Information
To identify the owner of a RUE, the initial INVITE for a call from a 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 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". 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 The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is
defined by [RFC2392] to locate message body parts. This URI type is defined by [RFC2392] to locate message body parts. This URI type is
present in a SIP message to convey the RUE ownership information as a 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 MIME body. The form of the RUE ownership information is a xCard
[RFC7095]. Please refer to [RFC6442] for an example of using [RFC6351]. for an example of using Content-Indirect URLs in SIP
Content-Indirect URLs in SIP messages. Note that use of the Content- messages. Note that use of the Content-Indirect URL usually implies
Indirect URL usually implies multiple message bodies ("mime/ multiple message bodies ("mime/multipart").
multipart").
5.2.4. Incoming Calls 5.2.4. Incoming Calls
The RUE MUST only accept inbound calls sent to it by a proxy The RUE MUST only accept inbound calls sent to it by a proxy
mentioned in the configuration. mentioned in the configuration.
If Multiple simultaneous RUE SIP registrations from different RUE If Multiple simultaneous RUE SIP registrations from different RUE
devices with the same SIP URI exist, the Provider MUST parallel fork 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 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 The first RUE to reply with a 200 OK answers the call and the
skipping to change at page 15, line 12 skipping to change at page 15, line 12
the configuration. If the SIP credentials fail, the RUE MUST query the configuration. If the SIP credentials fail, the RUE MUST query
the user. the user.
Synchronization using CardDAV MUST be a two-way synchronization Synchronization using CardDAV MUST be a two-way synchronization
service, with proper handling of asynchronous adds, changes, and service, with proper handling of asynchronous adds, changes, and
deletes at either end of the transport channel. deletes at either end of the transport channel.
7.2. Contacts Import/Export Service 7.2. Contacts Import/Export Service
Implementations MUST be able to export/import the list of contacts in Implementations MUST be able to export/import the list of contacts in
jCard [RFC7095] json format. jCard [RFC6351] json format.
The RUE accesses this service via the "contacts" URI in the The RUE accesses this service via the "contacts" URI in the
configuration. The URL MUST resolve to identify a web server configuration. The URL MUST resolve to identify a web server
resource that imports/exports contact lists for authorized users. resource that imports/exports contact lists for authorized users.
The RUE stores/retrieves the contact list (address book) by issuing The RUE stores/retrieves the contact list (address book) by issuing
an HTTPS POST or GET request. If the request triggers a challenge an HTTPS POST or GET request. If the request triggers a challenge
for digest authentication credentials, the RUE MUST attempt to for digest authentication credentials, the RUE MUST attempt to
continue using matching "credentials" from the configuration. If no continue using matching "credentials" from the configuration. If no
credentials are configured, the RUE MUST query the user. credentials are configured, the RUE MUST query the user.
skipping to change at page 31, line 48 skipping to change at page 31, line 48
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
Authoring and Versioning (WebDAV)", RFC 6352, Authoring and Versioning (WebDAV)", RFC 6352,
DOI 10.17487/RFC6352, August 2011, DOI 10.17487/RFC6352, August 2011,
<https://www.rfc-editor.org/info/rfc6352>. <https://www.rfc-editor.org/info/rfc6352>.
[RFC6764] Daboo, C., "Locating Services for Calendaring Extensions [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions
to WebDAV (CalDAV) and vCard Extensions to WebDAV to WebDAV (CalDAV) and vCard Extensions to WebDAV
(CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013,
<https://www.rfc-editor.org/info/rfc6764>. <https://www.rfc-editor.org/info/rfc6764>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting [RFC3842] Mahy, R., "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation Indication Event Package for the Session Initiation
Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August
2004, <https://www.rfc-editor.org/info/rfc3842>. 2004, <https://www.rfc-editor.org/info/rfc3842>.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, Context for Internet Mail", RFC 3458,
DOI 10.17487/RFC3458, January 2003, DOI 10.17487/RFC3458, January 2003,
<https://www.rfc-editor.org/info/rfc3458>. <https://www.rfc-editor.org/info/rfc3458>.
skipping to change at page 32, line 39 skipping to change at page 32, line 34
<https://www.rfc-editor.org/info/rfc7852>. <https://www.rfc-editor.org/info/rfc7852>.
[RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
<https://www.rfc-editor.org/info/rfc7874>. <https://www.rfc-editor.org/info/rfc7874>.
[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec
Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
<https://www.rfc-editor.org/info/rfc7742>. <https://www.rfc-editor.org/info/rfc7742>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
RFC 6351, DOI 10.17487/RFC6351, August 2011,
<https://www.rfc-editor.org/info/rfc6351>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021, DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/info/rfc8825>.
 End of changes. 9 change blocks. 
15 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/