-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-ietf-rtcweb-gateways.xml
280 lines (226 loc) · 11.8 KB
/
draft-ietf-rtcweb-gateways.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtcweb-gateways-01" ipr="trust200902">
<front>
<title abbrev="WebRTC Gateways">WebRTC Gateways</title>
<author fullname="Harald Alvestrand" initials="H. T." surname="Alvestrand">
<organization>Google</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Uwe Rauschenbach" initials="U." surname="Rauschenbach">
<organization>Nokia Networks</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date day="6" month="July" year="2015"/>
<workgroup>RTCWeb Working Group</workgroup>
<abstract>
<t>This document describes interoperability considerations for a class
of WebRTC-compatible endpoints called "WebRTC gateways", which
interconnect between WebRTC endpoints and devices that are not WebRTC
endpoints.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The WebRTC model described in <xref
target="I-D.ietf-rtcweb-overview"/> is focused on direct browser to
browser communication as its primary use case. Nevertheless, it is
clearly interesting to have WebRTC endpoints connect to other types of
devices, including but not limited to SIP phones, legacy phones,
CLUE-based teleconferencing systems, XMPP-based conferencing systems,
and entirely proprietary devices or systems.</t>
<t>WebRTC gateways are middle boxes which enable the exchange of media
streams between WebRTC endpoints on one side, and the other types of
devices mentioned above on the other side. To a WebRTC endpoint, the
gateway appears as a WebRTC-compatible endpoint.</t>
<t>This document describes the requirements that need to be placed on
such gateways, both the requirements on WebRTC endpoints that can be
relaxed and the additional requirements that need to be applied.</t>
<t>A WebRTC gateway appears as a WebRTC-compatible endpoint, and will
thus not be conformant with all requirements for a WebRTC endpoint (it
does not do everything a WebRTC endpoint does), but is able to
interoperate with WebRTC endpoints.</t>
<t>NOTE IN DRAFT: There is still not a WG consensus called on whether
this document is Informational or standards-track. If it becomes
informational, the use of RFC 2119 language is used to call attention to
features where non-conformance will render a gateway unable to
interoperate with WebRTC-based endpoints.</t>
<section title="Implications of the gateway environment">
<t>A gateway will be limited in the functionality it can offer by the
system or class of devices it is gatewaying to. For instance, a
gateway into the telephone system will not be able to relay data or
video, no matter how much it is required. Therefore, a number of
functions that are mandatory to support in WebRTC endpoints are not
mandatory on gateways; the requirement on the gateway is that it is
able to negotiate those features away correctly.</t>
</section>
<section title="Signalling model">
<t>The WebRTC model is that signalling is outside the scope of the
specification. This document does not change that.</t>
<t>Nevertheless, any practical gateway needs to deal with signalling.
For that, this document assumes that the overall system consists of an
application running in the WebRTC browser, possibly one or more
signalling relays that mediate signalling and thereby enable
communication between the application and the gateway, and the actual
gateway that is responsible for handling the media flows.</t>
<t>The application, the signalling relays (if any) and the gateway
together need to be able to:</t>
<t><list style="symbols">
<t>adhere to the offer/answer semantics</t>
<t>deal with the description of configuration coming from the
browser; this is specified in SDP format in the WebRTC browser
API</t>
<t>generate the information that is needed by the browser to set
up the session, and express that information in the form of
SDP.</t>
</list> The shorthand notation "The gateway MUST/SHOULD/MAY support
<SDP function xxx>" used below means that an application running
in the Web browser, the signalling relays, and the gateway together
MUST/SHOULD/MAY support this functionality; it is not a requirement
that this happens at the media gateway itself.</t>
</section>
</section>
<section title="WebRTC non-browser requirements that can be relaxed">
<t>WebRTC gateways are intended to communicate with WebRTC
endpoints<xref target="I-D.ietf-rtcweb-overview"/>. Some features that
typical WebRTC endpoints are required to support may be meaningless or
unneccesary for WebRTC gateways; some such things are noted in this
section. This lack of conformance means that a gateway is considered a
WebRTC-compatible endpoint, not a WebRTC endpoint (unless a particular
gateway claims to be a WebRTC endpoint, which it is of course allowed to
do).</t>
<t>A WebRTC gateway which is expected to be deployed where it can be
reached with a static IP address (as seen from the client) does not need
to support full ICE; it therefore MAY implement ICE-Lite only.</t>
<t>ICE-Lite implementations do not send consent checks, so a gateway MAY
choose not to send consent checks too, but MUST respond to consent
checks it receives.</t>
<t>A gateway with a static IP address is expected to not need to hide
its location, so it does not need to support functionality for operating
only via a TURN server; instead it MAY choose to produce Host ICE
candidates only.</t>
<t>If a gateway serves as a media relay into another RTP domain, it MAY
choose to support only features available in that network. This means
that it MAY choose to not support Bundle and any of the RTP/RTCP
extensions related to it, RTCP-Mux, or Trickle Ice. However, the gateway
MUST support DTLS-SRTP, since this is required for interworking with
WebRTC endpoints.</t>
<t>Note that non-support of BUNDLE means that "bundle-only" tracks are
not supported. This means that applications using an RTCBundlePolicy
other than "max-compat" (<xref target="I-D.ietf-rtcweb-jsep"/> section
4.1.1) can only use one track of each media type.</t>
<t>If a gateway serves as a media relay into a network or to devices not
implementing the WebRTC Datachannel, it MAY choose to not support the
Datachannel.</t>
</section>
<section title="Additional WebRTC gateway requirements">
<t>(nothing yet)</t>
</section>
<section title="Considerations for SDP-using networks">
<t>Some networks that are gatewayed into, such as SIP networks, will
also use SDP to represent the media configurations. Gateways will,
however, need to inspect and probably modify the SDP passed between the
SDP-using network and the WebRTC endpoints to achieve maximum
interoperability.</t>
<t>Considerations include:</t>
<t><list style="symbols">
<t>If a correspondent does not offer the features WebRTC depends on,
connections will not complete. The support for dtls-srtp, shown by
the "fingerprint" attribute, is the most obvious example. The
gateway is probably better off either ending such calls early or
acting as a full B2BUA (as defined in <xref target="RFC3261"/>) with
media gatewaying.</t>
<t>If a correspondent makes an offer using features that are not
required by JSEP, these may not be understood by the WebRTC
implementation. The gateway may choose to strip out some such
features.</t>
<t>Certain ancient practices (such as using port 0 to place a media
section on hold with the intent of resuming it later) are not
conformant with the SDP offer/answer spec (<xref target="RFC3264"/>
section 8.2). Since WebRTC implementations are expected to be SDP
offer/answer conformant, such practices may need to be stripped out
by the gateway</t>
</list>[NOTE IN DRAFT: This section may need expanding.]</t>
<t/>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>A WebRTC gateway may operate in two security modes: Security-context
termination and security-context relaying.</t>
<t>Relaying is only possible where signed and encrypted content can be
passed through unchanged, and where keys can be exchanged directly
between the endpoints.</t>
<t>When the gateway terminates the security context, it means that the
WebRTC user has to place trust in the gateway to perform all
verification of identity and protection of content in the realm on the
other side of the gateway; there is no way the end-user can detect a
man-in-the-middle attack, an identity spoofing attack or a recording
done at the gateway. For many scenarios, this is not going to be seen as
a problem, but needs to be considered when one decides to use a
gatewayed service.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Several comments from Christer Holmberg and Andrew Hutton were
included.</t>
</section>
<section title="Change history">
<t>Changes from draft-alvestrand-rtcweb-gateways-00 <list
style="symbols">
<t>Aligned terminology with draft-rtcweb-overview-12</t>
<t>Rewrote text on signaling to improve clarity</t>
<t>Editorial nits</t>
</list></t>
<t>Changes from draft-alvestrand-rtcweb-gateways-01 <list
style="symbols">
<t>Aligned terminology with draft-rtcweb-overview-13
("non-browser")</t>
<t>Nits</t>
</list></t>
<t>Changes from draft-alvestrand-rtcweb-gateways-02 <list
style="symbols">
<t>Re-submitted as WG draft</t>
<t>Addressed a comment from Andrew Hutton that deployment in open
internet is an option, not a fact.</t>
</list>Changes from draft-ietf-rtcweb-gateways-00</t>
<t><list style="symbols">
<t>Added note about impllications of non-support of BUNDLE</t>
<t>Added "Considerations for SDP-using networks" section</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-rtcweb-jsep'?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3264'?>
</references>
</back>
</rfc>