idnits 2.17.1
draft-ietf-stox-media-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 20, 2015) is 3201 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)
** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0030'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0166'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0167'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0176'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0177'
== Outdated reference: A later version (-18) exists of
draft-ietf-mmusic-trickle-ice-sip-02
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- Obsolete informational reference (is this intentional?): RFC 3555
(Obsoleted by RFC 4855, RFC 4856)
-- Obsolete informational reference (is this intentional?): RFC 5766
(Obsoleted by RFC 8656)
-- Obsolete informational reference (is this intentional?): RFC 7230
(Obsoleted by RFC 9110, RFC 9112)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Saint-Andre
3 Internet-Draft &yet
4 Intended status: Standards Track S. Ibarra
5 Expires: January 21, 2016 AG Projects
6 E. Ivov
7 Jitsi
8 July 20, 2015
10 Interworking between the Session Initiation Protocol (SIP) and the
11 Extensible Messaging and Presence Protocol (XMPP): Media Sessions
12 draft-ietf-stox-media-07
14 Abstract
16 This document defines a bidirectional protocol mapping for use by
17 gateways that enable the exchange of media signaling messages between
18 systems that implement the Session Initiation Protocol (SIP) and
19 systems that implement the Jingle extensions to the Extensible
20 Messaging and Presence Protocol (XMPP).
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on January 21, 2016.
39 Copyright Notice
41 Copyright (c) 2015 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 4
58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 4. Compatibility with Offer/Answer Model and Interactive
60 Connectivity Establishment . . . . . . . . . . . . . . . . . 5
61 5. Syntax Mappings . . . . . . . . . . . . . . . . . . . . . . . 6
62 5.1. Generic Jingle Syntax . . . . . . . . . . . . . . . . . . 6
63 5.2. Application Formats . . . . . . . . . . . . . . . . . . . 10
64 5.3. Raw UDP Transport Method . . . . . . . . . . . . . . . . 10
65 5.4. ICE-UDP Transport Method . . . . . . . . . . . . . . . . 10
66 6. Transport Fallback . . . . . . . . . . . . . . . . . . . . . 11
67 7. Call Hold . . . . . . . . . . . . . . . . . . . . . . . . . . 12
68 8. Early Media . . . . . . . . . . . . . . . . . . . . . . . . . 13
69 9. Detecting Endless Loops . . . . . . . . . . . . . . . . . . . 14
70 10. SDP Format-Specific Parameters . . . . . . . . . . . . . . . 14
71 11. Dialog Forking . . . . . . . . . . . . . . . . . . . . . . . 16
72 12. Sample Call Flow . . . . . . . . . . . . . . . . . . . . . . 17
73 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
74 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
75 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
76 15.1. Normative References . . . . . . . . . . . . . . . . . . 24
77 15.2. Informative References . . . . . . . . . . . . . . . . . 25
78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
81 1. Introduction
83 The Session Initiation Protocol [RFC3261] is a widely-deployed
84 technology for the management of media sessions (such as voice and
85 video calls) over the Internet. SIP itself provides a signaling
86 channel via TCP [RFC0793] or UDP [RFC0768], over which two or more
87 parties can exchange messages for the purpose of negotiating a media
88 session that uses a dedicated media channel such as the Real-time
89 Transport Protocol (RTP) [RFC3550]. The Extensible Messaging and
90 Presence Protocol (XMPP) [RFC6120] also provides a signaling channel,
91 typically via TCP (although bindings for HTTP [XEP-0124] and
92 WebSocket [RFC7395] also exist).
94 Given the significant differences between XMPP and SIP, traditionally
95 it was difficult to combine the two technologies in a single user
96 agent (although nowadays such implementations are not uncommon, as
97 described in [RFC7081]). Thus in 2005 some developers wishing to add
98 media session capabilities to XMPP clients defined a set of XMPP-
99 specific session negotiation protocol extensions called Jingle (see
100 especially [XEP-0166], [XEP-0167], and [XEP-0176]).
102 Jingle was designed to easily map to SIP for communication through
103 gateways or other transformation mechanisms. Nevertheless, given the
104 significantly different technology assumptions underlying XMPP and
105 SIP, Jingle is different from SIP in several important respects:
107 o Base SIP messages and headers use a plaintext format similar in
108 some ways to the Hypertext Transport Protocol [RFC7230], whereas
109 Jingle messages are pure XML. Mappings between SIP headers and
110 Jingle message syntax are provided below.
112 o SIP payloads for session semantics use the Session Description
113 Protocol [RFC4566], whereas the equivalent Jingle payloads use XML
114 child elements of the Jingle element. However, the
115 Jingle specifications defining such child elements specify
116 mappings to SDP for all Jingle syntax, making the mapping
117 relatively straightforward.
119 o SIP messages have historically often been transported over UDP,
120 whereas the signaling channel for Jingle is XMPP over TCP.
121 Mapping between the transport layers typically happens within a
122 gateway using techniques below the application level, and
123 therefore is not addressed in this specification.
125 Consistent with existing specifications for mapping between SIP and
126 XMPP (see [RFC7247]), this document describes a bidirectional
127 protocol mapping for use by gateways that enable the exchange of
128 media signaling messages between systems that implement SIP and
129 systems that implement the XMPP Jingle extensions.
131 It is important to note that SIP and Jingle sessions could be
132 gatewayed in a very simple way if all media were always routed and
133 potentially even transcoded through the same gateway used for
134 signaling. By contrast, this specification defines a mapping that
135 allows gateways to only intervene at the signaling level, thus
136 letting user agents exchange media in an end-to-end or peer-to-peer
137 manner without intervention by a specialized gateway (naturally, a
138 media relay that supports TURN [RFC5766] might be used). Such
139 signaling-only gateways focus on handling session establishment and
140 control within the context of what users would perceive as "calls".
141 This document is hence primarily dealing with calling scenarios as
142 opposed to generic media sessions or specialized sessions for
143 functionality such as file transfer (see [RFC5547] and [XEP-0234]).
145 2. Intended Audience
147 The documents in this series are intended for use by software
148 developers who have an existing system based on one of these
149 technologies (e.g., SIP), and would like to enable communication from
150 that existing system to systems based on the other technology (e.g.,
151 XMPP). We assume that readers are familiar with the core
152 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the
153 base document for this series [RFC7247], and with the following
154 media-related specifications:
156 o RTP Profile for Audio and Video Conferences with Minimal Control
157 [RFC3551]
159 o The Secure Real-time Transport Protocol (SRTP) [RFC3711]
161 o SDP: Session Description Protocol [RFC4566]
163 o Interactive Connectivity Establishment (ICE): A Protocol for
164 Network Address Translator (NAT) Traversal for Offer/Answer
165 Protocols [RFC5245]
167 o Jingle [XEP-0166]
169 o Jingle RTP Sessions [XEP-0167]
171 o Jingle ICE-UDP Transport Method [XEP-0176]
173 o Jingle Raw UDP Transport Method [XEP-0177]
175 3. Terminology
177 A number of technical terms used here are defined in [RFC3261],
178 [RFC6120], [XEP-0166], and [XEP-0167]. The term "JID" is short for
179 "Jabber Identifier".
181 In flow diagrams, SIP traffic is shown using arrows such as "***>"
182 whereas XMPP traffic is shown using arrows such as "...>".
184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
186 "OPTIONAL" in this document are to be interpreted as described in
187 [RFC2119].
189 4. Compatibility with Offer/Answer Model and Interactive Connectivity
190 Establishment
192 Even if Jingle semantics have many similarities with those used in
193 SIP, there are some use cases that cannot be handled in exactly the
194 same way due to the Offer/Answer model used in SIP in conjunction
195 with SDP.
197 More specifically, mapping SIP and SDP Offer/Answer to XMPP is often
198 complicated due to the difference in how each handles backward
199 compatibility. Jingle, as most other XMPP extensions, relies heavily
200 on the XMPP extension for service discovery [XEP-0030], which implies
201 that XMPP entities are able to verify the capabilities of their
202 intended peer before attempting to establish a session with it.
204 SDP Offer/Answer, on the other hand, uses a "least common
205 denominator" approach where every SDP offer needs to be
206 comprehensible by legacy endpoints. Newer, unsupported aspects in
207 this offer can therefore only appear as optional, or their use needs
208 to be limited to subsequent Offer/Answer exchanges once their support
209 has been confirmed.
211 In particular, many older SIP endpoints do not support Interactive
212 Connectivity Establishmen (ICE) [RFC5245]. A signaling gateway from
213 Jingle to SIP has two primary alternatives for dealing with such
214 endpoints on the SIP side:
216 o Require the use of ICE and otherwise fail the call by including
217 the "Require: ice" SIP option tag [RFC5768] in the SIP INVITE that
218 it sends on behalf of the Jingle initiator.
220 o Send an initial SIP INVITE for an ICE connection and, if the SIP
221 endpoint indicates that it cannot handle ICE, send a re-INVITE for
222 a non-ICE connection to the SIP endpoint and a Jingle transport-
223 replace for a Raw UDP connection to the Jingle endpoint. (This
224 will introduce a potentialy large delay and might not result in a
225 much higher percentage of calls succeeding unless the signaling
226 gateway also offers a TURN [RFC5766] service for NAT traversal.)
227 See Section 6 for further discussion.
229 Use of "Trickle ICE" is one significant example where this issue
230 occurs. From the beginning, Jingle supported the trickling of
231 candidates (via Jingle messages of type 'transport-info'), and only
232 years later was this behavior generalized
233 [I-D.ietf-mmusic-trickle-ice] and then ported to SIP
234 [I-D.ietf-mmusic-trickle-ice-sip]. Therefore SIP endpoints need to
235 always behave like so-called "vanilla ICE" agents when sending their
236 first offer and make sure they gather all candidates before sending a
237 SIP INVITE. This is necessary because otherwise ICE agents with no
238 support for trickling of candidates can prematurely declare failure.
239 Jingle endpoints, on the other hand, can verify support for trickling
240 of candidates prior to engaging in a session and adapt their behavior
241 accordingly (and, as noted, trickling of candidates is standard
242 operating procedure in Jingle).
244 In order to work around this disparity in relation to communication
245 of transport candidates, the Jingle RTP transport method [XEP-0176]
246 defines a mode for supporting traditional Offer/Answer interactions
247 through the "urn:ietf:rfc:3264" feature tag. When an XMPP entity
248 such as a client (or, significantly, a gateway to a SIP system)
249 advertises support for this feature, the entity indicates that it
250 needs to receive multiple transport candidates in the initial offer,
251 instead of receiving them trickled over time. Although
252 implementations conforming to this specification MUST support the
253 Offer/Answer model with Jingle, such endpoints SHOULD NOT actually
254 declare support for the "urn:ietf:rfc:3264" service discovery feature
255 since this would mean that they too would be reachable only through
256 Offer/Answer semantics and not also through trickle-ICE semantics.
258 The difference in handling of transport candidates also has an impact
259 on ICE restarts (see Section 9.1.1.1 of [RFC5245]). Because Jingle
260 endpoints can send candidates at any time, when communicating
261 directly with other Jingle endpoints they would not initiate an ICE
262 restart simply in order to send a candidate that, for example,
263 changes the media target. However, as part of support for the Offer/
264 Answer model a Jingle endpoint would instead need to initiate an ICE
265 restart when communicating with a SIP endpoint or gateway that does
266 not support trickle ICE. Similarly, a Jingle endpoint needs to
267 support the 'generation' attribute (used to signal an ICE restart)
268 when communicating with a SIP endpoint or gateway that does not
269 support trickle ICE. See also the syntax discussion under
270 Section 5.4.
272 5. Syntax Mappings
274 5.1. Generic Jingle Syntax
276 Jingle is designed in a modular fashion, so that session description
277 data is generally carried in a payload within high-level Jingle
278 elements, i.e., the element and its child. The
279 following example illustrates this structure, where the XMPP stanza
280 is a request to initiate an audio session (via the and
281 elements) using a transport of RTP over raw UDP (via
282 the element).
284 Example 1: Structure of a Jingle session initiation request
286 |
290 |
294 |
298 |
299 |
300 |
301 |
305 |
306 |
307 |
308 |
312 |
313 |
314 |
315 |
317 The syntax and semantics of the and elements are
318 defined in the core Jingle specification [XEP-0166], the syntax and
319 semantics of the element qualified by the
320 'urn:xmpp:jingle:app:rtp:1' namespace are defined in the Jingle RTP
321 specification [XEP-0167], and the syntax and semantics of the
322 element qualified by the 'urn:xmpp:jingle:transport:raw-
323 udp' namespace are defined in the Jingle Raw UDP specification
324 [XEP-0177]. Other elements are defined in
325 specifications for the appropriate application types (see for example
326 [XEP-0234] for file transfer) and other elements are
327 defined in the specifications for appropriate transport methods (see
328 for example [XEP-0176], which defines an XMPP profile of ICE
329 [RFC5245]).
331 At the core Jingle layer, the following mappings are defined.
333 Table 1: High-Level Mapping from XMPP to SIP
335 +--------------------------------+--------------------------------+
336 | Jingle | SIP |
337 +--------------------------------+--------------------------------+
338 | 'action' | [ see next table ] |
339 +--------------------------------+--------------------------------+
340 | 'initiator' | [ no mapping ] |
341 +--------------------------------+--------------------------------+
342 | 'responder' | [ no mapping ] |
343 +--------------------------------+--------------------------------+
344 | 'sid' | local-part of Dialog ID |
345 +--------------------------------+--------------------------------+
346 | local-part of 'initiator' | in SDP o= line |
347 +--------------------------------+--------------------------------+
348 | 'creator' | [ no mapping ] |
349 +--------------------------------+--------------------------------+
350 | 'name' | no mandatory mapping (1) |
351 +--------------------------------+--------------------------------+
352 | 'senders' value of | a= line of sendrecv, recvonly, |
353 | both, initiator, responder, or | sendonly, or inactive |
354 | none | |
355 +--------------------------------+--------------------------------+
357 1. In can be appropriate to map to the a=mid value defined in
358 [RFC5888].
360 The 'senders' attribute is optional in Jingle, with a default value
361 of "both"; thus in case the attribute is absent the SDP direction
362 value MUST be considered as 'sendrecv'.
364 The 'action' attribute of the element has 15 allowable
365 values. In general they should be mapped as shown in the following
366 table, with some exceptions as described below.
368 Table 2: Mapping of Jingle Actions to SIP Methods
370 +-------------------+------------------------------+
371 | Jingle Action | SIP Method |
372 +-------------------+------------------------------+
373 | content-accept | INVITE response (1xx or 2xx) |
374 +-------------------+------------------------------+
375 | content-add | INVITE request |
376 +-------------------+------------------------------+
377 | content-modify | re-INVITE request |
378 +-------------------+------------------------------+
379 | content-reject | unused in this mapping |
380 +-------------------+------------------------------+
381 | content-remove | INVITE request |
382 +-------------------+------------------------------+
383 | description-info | unused in this mapping |
384 +-------------------+------------------------------+
385 | security-info | unused in this mapping |
386 +-------------------+------------------------------+
387 | session-accept | INVITE response (1xx or 2xx) |
388 +-------------------+------------------------------+
389 | session-info | see note (1) below |
390 +-------------------+------------------------------+
391 | session-initiate | INVITE request |
392 +-------------------+------------------------------+
393 | session-terminate | BYE |
394 +-------------------+------------------------------+
395 | transport-accept | unused in this mapping |
396 +-------------------+------------------------------+
397 | transport-info | see note (2) below |
398 +-------------------+------------------------------+
399 | transport-reject | unused in this mapping |
400 +-------------------+------------------------------+
401 | transport-replace | unused in this mapping |
402 +-------------------+------------------------------+
404 1. The Jingle session-info action can be used for multiple purposes,
405 such as putting the session on hold or sending a ringing
406 indication. In particular, a session-info action of type
407 'ringing' SHOULD be mapped to a 180 SIP provisional response.
408 The use of session-info for the purpose of session hold is
409 described in Section 7.
411 2. In Jingle the transport-info action is used to exchange transport
412 candidates after the initial offer, as documented in [XEP-0176].
413 This usage has been generalized as "Trickle ICE"
414 [I-D.ietf-mmusic-trickle-ice] and has also been extended to SIP
415 [I-D.ietf-mmusic-trickle-ice-sip]. Therefore a Jingle action of
416 transport-info SHOULD be mapped to a SIP INFO request, but only
417 in cases where it is reasonable to assume that the SIP endpoint
418 or gateway supports trickle ICE. See Section 4 for further
419 discussion.
421 5.2. Application Formats
423 Jingle application formats for audio and video exchange via RTP are
424 specified in [XEP-0167]. These application formats effectively map
425 to the "RTP/AVP" profile specified in [RFC3551] and the "RTP/SAVP"
426 profile specified in [RFC3711], where the media types are "audio" and
427 "video" and the specific mappings to SDP syntax are provided in
428 [XEP-0167].
430 (As stated in [XEP-0167], future versions of that specification might
431 define how to use other RTP profiles such as "RTP/AVPF" and "RTP/
432 SAVPF" as defined in [RFC4585] and [RFC5124] respectively.)
434 5.3. Raw UDP Transport Method
436 A basic Jingle transport method for exchanging media over UDP is
437 specified in [XEP-0177]. This "Raw UDP" transport method involves
438 the negotiation of an IP address and port only. It does not provide
439 NAT traversal, effectively leaving the task to intermediary entities
440 (which might be a media relay associated with but functionally
441 independent of a signaling gateway). The Jingle 'ip' attribute maps
442 to the connection-address parameter of the SDP c= line and the 'port'
443 attribute maps to the port parameter of the SDP m= line. Use of SIP
444 without ICE would generally map to use of Raw UDP on the XMPP side of
445 a session.
447 5.4. ICE-UDP Transport Method
449 A more advanced Jingle transport method for exchanging media over UDP
450 uses Interactive Connectivity Establishment and is specified in
451 [XEP-0176]. By following the ICE methodology specified in [RFC5245],
452 ideally this transport method provides NAT traversal for media.
454 The relevant SDP mappings are provided in [XEP-0176]. However, those
455 who implement signaling gateways need to be aware of a few syntax
456 incompatibilities that need to be addressed by gateways conforming to
457 this specification:
459 o The 'foundation' attribute is defined as a number in Jingle
460 (unsigned byte) whereas ICE [RFC5245] defines it as a string,
461 which can contain letters, digits and the '+' and '/' symbols.
462 Gateway applications MUST therefore convert ICE originating
463 foundations into integer numbers and they MUST guarantee that such
464 a conversion preserves foundation uniqueness. The exact mechanism
465 for the conversion is undefined.
467 o Jingle defines a 'generation' attribute which is used to determine
468 if an ICE restart is required. This attribute has no counterpart
469 in SIP because ICE restarts are initiated by detecting a change in
470 the ICE 'ufrag' and 'pwd' (see Section 9.1.1.1 of [RFC5245]).
471 Gateways MUST therefore increase the generation number when they
472 detect such a change.
474 o The 'id' attribute defined by Jingle has no SIP counterpart; thus
475 applications are free to choose means to generate unique
476 identifiers across the different candidates of an ICE generation.
478 o The 'network' attribute defined by Jingle has no counterpart in
479 SIP and SHOULD be ignored.
481 6. Transport Fallback
483 Most Jingle endpoints will first attempt to use ICE as specified for
484 Jingle in [XEP-0176] (since that is most likely to result in NAT
485 traversal) and only if that does not succeed will they fall back to
486 raw UDP [XEP-0177]. This fallback approach is described in the
487 Jingle ICE specification [XEP-0176].
489 However, that approach depends on the use of XMPP service discovery
490 [XEP-0030]. Because SIP does not have a method for determining
491 endpoint capabilities, SIP endpoints use what can be termed "single-
492 exchange fallback": they first try one method and if that fails they
493 then send a re-INVITE with the second method.
495 One way to map single-exchange fallback to Jingle is for the Jingle
496 endpoint to attempt ICE first and send a transport-replace if the SIP
497 answer indicates no support for ICE, then send a SIP re-INVITE with
498 the addresses in the transport-accept. Unfortunately, this approach
499 will result a fairly substantial post-answer delay before media can
500 flow.
502 Because such delays usually result in an unacceptable user
503 experience, the trend for many calling applications is to first send
504 only a candidate that is known beforehand to be highly likely to
505 result in NAT traversal, which is almost always a candidate at a
506 media relay (i.e., an ICE candidate of type "relay"). Such
507 applications will then offer and perhaps switch to a host candidate,
508 peer reflexive candidate, or server reflexive candidate only after
509 media is flowing via the relayed candidate. This approach obviates
510 the need for transport fallback from ICE to raw UDP during call
511 setup, and instead works around the problem by using trickle ICE (for
512 those endpoints that support it) or re-INVITEs with updated transport
513 candidates after call setup has been completed.
515 7. Call Hold
517 The Offer/Answer model [RFC3264] stipulates that streams are placed
518 on hold by setting their direction to "sendonly". A session is
519 placed on hold by doing this for all the streams it contains. The
520 same semantics are also supported by Jingle through the "senders"
521 element and its "initiator" and "responder" values (the Jingle
522 specification also defines a value of "none", which maps to an a=
523 value of "inactive", and a default value of "both", which maps to an
524 a= value of "sendrecv").
526 The following example shows how the responder would put the call on
527 hold (i.e., temporarily stop listening to media sent by the
528 initiator) using a Jingle content-modify action and a modified value
529 for the 'senders' attribute (here a value of "responder" is used to
530 indicate that the responder might continue to send media, such as
531 hold music).
533 Example 2: Call hold via 'senders' attribute
535 |
539 |
543 |
547 |
548 |
550 In addition to these semantics, however, the Jingle RTP Sessions
551 specification [XEP-0167] also defines a more concise way for
552 achieving the same end, which consists in sending a "hold" command
553 within a "session-info" action, as shown in the following example.
555 Example 3: Call hold via session-info action
557 |
561 |
565 |
566 |
567 |
569 Gateways that receive either of the foregoing hold notifications from
570 their Jingle side MUST generate a new offer on their SIP side,
571 placing all streams in a "sendonly" state.
573 When relaying offers from SIP to XMPP, gateways are not required to
574 translate "sendonly" attributes into a "hold" command as this would
575 not always be possible (e.g., when not all streams have the same
576 direction). Additionally, such conversions might introduce
577 complications in case further offers placing a session on hold also
578 contain other session modifications.
580 It is possible that, after one entity has put the other on hold, the
581 second entity might put the first entity on hold. In this case, the
582 effective direction would then be "inactive" in SDP and "none" in
583 Jingle.
585 8. Early Media
587 [RFC3959] and [RFC3960] describe a number of scenarios relying on
588 "early media". While similar attempts have also been made for XMPP,
589 support for early media is not currently widely supported in Jingle
590 implementations. Therefore, gateways SHOULD NOT forward SDP answers
591 from SIP to Jingle until a final response has been received, except
592 in cases where the gateway is in a position to confirm specific
593 support for early media by the endpoint (one approach to such support
594 can be found in [XEP-0269] but it has not yet been standardized).
596 Gateways MUST however store early media SDP answers when they are
597 sent inside a reliable provisional response. In such cases, a
598 subsequent final response can follow without an actual answer and the
599 one from the provisional response will need to be forwarded to the
600 Jingle endpoint.
602 9. Detecting Endless Loops
604 [RFC3261] defines a "Max-Forwards" header that allows intermediate
605 entities such as SIP proxies to detect and prevent loops from
606 occurring. The specifics of XMPP make such a prevention mechanism
607 unnecessary for XMPP-only environments. With the introduction of
608 SIP-to-XMPP gatewaying, however, it would be possible for loops to
609 occur where messages are being repeatedly forwarded from XMPP to SIP
610 to XMPP to SIP. This can happen not only between two endpoints, but
611 also with the addition of a third endpoint into the mix (e.g.,
612 because one of the two original endpoints forwards a call to a third
613 endpoint, thus converting a "spiral" into a loop).
615 To compensate for the lack of a "Max-Forwards" header in SIP,
616 gateways MUST therefore keep track of all SIP transactions and Jingle
617 sessions that they are currently serving and they MUST block re-
618 entrant messages. Although the specifics of such tracking are a
619 matter of implementation, the broad requirements is to consistently
620 translate SIP dialog IDs into Jingle session ID, and vice versa, or
621 generate an internal identifier for each session (e.g., by
622 concatenating or hashing the combination of the SIP dialog ID and the
623 Jingle session ID).
625 10. SDP Format-Specific Parameters
627 The SDP specification [RFC4566] defines "a=fmtp" attributes for the
628 transmission of format-specific parameters as a single transparent
629 string. Such strings can be used to convey either a single value or
630 a sequence of parameters, separated by semi-colons, commas, or
631 whatever delimiters are chosen by a particular payload type
632 specification.
634 The Jingle RTP application format [XEP-0167], on the other hand,
635 defines a element as follows:
637
639 A sequence of parameters is thus transmitted as an array of distinct
640 name/value pairs, at least in the context of the Jingle RTP
641 extension.
643 These differences make it difficult to devise a generic mechanism
644 that accurately translates format parameters from Jingle RTP to SDP
645 without the specifics of the payload being known to the gateway. In
646 general this is not a major problem because most of the media type
647 definitions supported in existing Jingle implementations follow the
648 semicolon-separated parameter model (e.g., typical audio and video
649 codecs). Possible exceptions include:
651 o The RTP Payload for DTMF Digits, Telephony Tones, and Telephony
652 Signals (i.e., the "audio/telephone-event" payload type). As
653 noted in Section 2.5.1.1 of [RFC4733], in SDP the "events"
654 parameter is assumed to indicate support for DTMF events 0-15 even
655 if the parameter is not included; a gateway SHOULD explicitly
656 indicate this support in a Jingle parameter with name='events' and
657 value='0-15'.
659 o The RTP Payload for Redundant Audio Data (i.e., the "audio/red"
660 payload type). Although this payload type is defined in
661 [RFC2198], the SDP representation is specified in Section 4.1.21
662 of [RFC3555] (note that this representation was not updated by
663 [RFC4856]). In particular, the "pt" parameter can be mapped to
664 a=fmtp lines as described in the payload type registration.
666 For implementations that wish to provide a general-purpose
667 translation method, this specification makes the following
668 recommendations:
670 1. Gateways that are aware of the formats in use SHOULD parse all
671 format parameters and generate arrays and "a=fmtp"
672 values accordingly.
674 2. When translating Jingle RTP to SIP, gateways that have no
675 explicit support for the formats that are being negotiated SHOULD
676 convert the list of elements into a single string,
677 containing a sequence of "name=value" pairs, separated by a semi-
678 colon and a space (i.e. "; ").
680 3. When translating SIP to Jingle RTP, gateways that have no
681 explicit support for the formats that are being negotiated SHOULD
682 tokenize the "a=fmtp" format string using one delimiter from the
683 following list: ";", "; ", ",", ", ". The resulting tokens
684 SHOULD then be parsed as "name=value" pairs. If this process
685 does actually yield any such pairs, they SHOULD be used for
686 generating the respective elements. If some of the
687 tokens cannot be parsed into a "name=value" pair because they do
688 not conform to the convention suggested in [RFC4855], or in case
689 the format string could not be tokenized with the above
690 delimiters, the remaining strings SHOULD be used as a value for
691 the "value" attribute of the element and the
692 corresponding "name" attribute SHOULD be left empty.
694 Here is a relatively simple example of the foregoing transformations,
695 using the aforementioned example of the "audio/telephone-event"
696 payload type (wherein the "events" parameter is implicitly named in
697 the SDP):
699 SDP with format data (audio/telephone-event)
701 a=rtpmap:100 telephone-event/8000
702 a=fmtp:100 0-15,66,70
704 Jingle transformation (audio/telephone-event)
706
708 A more complicated example would be handling of the "audio/red"
709 payload type (wherein the "pt" parameter can be mapped to a=fmtp
710 lines as described in [RFC3555]):
712 SDP with format data (audio/red)
714 m=audio 49170 RTP/AVP 99 0 103
715 a=rtpmap:99 RED/8000
716 a=fmtp:99 0/103
717 a=rtpmap:103 G729D/8000
718 a=fmtp:103 annexb=yes
720 Jingle transformation (audio/red)
722
723
725 11. Dialog Forking
727 The core SIP specification [RFC3261] defines semantics for dialog
728 forking. Such semantics have not been defined for Jingle and need to
729 be hidden from XMPP endpoints.
731 To achieve this, a SIP-to-XMPP gateway MUST NOT forward more than one
732 provisional response on the Jingle side. Typically they would do so
733 only for the first provisional response they receive and ignore the
734 rest. This provisional response SHOULD be forwarded as if it
735 originated from a "user@host" address (i.e., a "bare JID")
736 corresponding to the AOR URI found in the "From" header of the SIP
737 provisional response. The gateway MUST NOT attempt to translate
738 GRUUs into full JIDs because it cannot know at this stage which of
739 the dialogs established by these provisional responses will be used
740 for the actual session.
742 Likewise, a gateway conforming to this specification MUST NOT forward
743 more than a single final response received through SIP to the Jingle
744 side. The gateway SHOULD terminate the SIP sessions whose received
745 final response was not forwarded to the Jingle side.
747 12. Sample Call Flow
749 The section illustrates the protocol flow of a basic voice chat
750 session in which an XMPP user (juliet@example.com) is the initiator
751 and a SIP user (romeo@example.net) is the responder. The signaling
752 is communicated through a gateway. To simplify the example, the
753 Jingle transport method negotiated is "raw UDP" as specified in
754 [XEP-0177].
756 XMPP XMPP SIP SIP
757 User Server Server User
758 | + X2S GW | |
759 | | | |
760 | (F1) XMPP | | |
761 | session- | | |
762 | initiate | | |
763 |...........>| | |
764 | (F2) XMPP | | |
765 | IQ-result | | |
766 |<...........| | |
767 | | (F3) SIP | |
768 | | INVITE | |
769 | |***********>| |
770 | | | (F4) SIP |
771 | | | INVITE |
772 | | |**********>|
773 | | | (F5) SIP |
774 | | | 180 |
775 | | | ringing |
776 | | |<**********|
777 | | (F6) SIP | |
778 | | 180 ringing| |
779 | |<***********| |
780 | (F7) XMPP | | |
781 | session- | | |
782 | info | | |
783 | (ringing) | | |
784 |<...........| | |
785 | (F8) XMPP | | |
786 | IQ-result | | |
787 |...........>| | |
788 | | | (F9) SIP |
789 | | | 200 OK |
790 | | |<**********|
791 | | (F10) SIP | |
792 | | 200 OK | |
793 | |<***********| |
794 | (F11) XMPP | | |
795 | session- | | |
796 | accept | | |
797 |<...........| | |
798 | (F12) XMPP | | |
799 | IQ-result | | |
800 |...........>| | |
801 | | (F13) SIP | |
802 | | ACK | |
803 | |***********>| |
804 | | | (F14) SIP |
805 | | | ACK |
806 | | |**********>|
807 | | | |
808 |<=======MEDIA SESSION OVER RTP======>|
809 | | | |
810 | | | (F15) SIP |
811 | | | BYE |
812 | | |<**********|
813 | | (F16) SIP | |
814 | | BYE | |
815 | |<***********| |
816 | (F17) XMPP | | |
817 | session- | | |
818 | terminate | | |
819 |<...........| | |
820 | (F18) XMPP | | |
821 | IQ-result | | |
822 |...........>| | |
824 The packet flow is as follows.
826 First the XMPP user sends a Jingle session-initiation request to the
827 SIP user.
829 Example 4: Jingle session-initiate (F1)
831 |
835 |
839 |
842 |
843 |
844 |
845 |
846 |
847 |
848 |
850 |
851 |
852 |
853 |
855 The gateway returns an XMPP IQ-result to the initiator on behalf of
856 the responder.
858 Example 5: XMPP IQ-result from gateway (F2)
860 |
865 The gateway transforms the Jingle session-initiate action into a SIP
866 INVITE.
868 Example 6: SIP transformation of Jingle session-initiate (F3)
870 | INVITE sip:romeo@example.net SIP/2.0
871 | Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
872 | Max-Forwards: 70
873 | From: Juliet Capulet ;tag=t3hr0zny
874 | To: Romeo Montague
875 | Call-ID: 3848276298220188511@example.com
876 | CSeq: 1 INVITE
877 | Contact:
878 | Content-Type: application/sdp
879 | Content-Length: 184
881 | v=0
882 | o=alice 2890844526 2890844526 IN IP4 client.example.com
883 | s=-
884 | c=IN IP4 192.0.2.101
885 | t=0 0
886 | m=audio 49172 RTP/AVP 18 96 97
887 | a=rtpmap:96 sppex/16000
888 | a=rtpmap:97 speex/8000
889 | a=rtpmap:18 G729
891 The responder returns a SIP 180 Ringing message.
893 Example 7: SIP 180 Ringing message (F5)
895 | SIP/2.0 180 Ringing
896 | Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
897 | received=192.0.2.101
898 | From: Juliet Capulet ;tag=t3hr0zny
899 | To: Romeo Montague ;tag=v3rsch1kk3l1jk
900 | Call-ID: 3848276298220188511@example.com
901 | CSeq: 1 INVITE
902 | Contact:
903 | Content-Length: 0
905 The gateway transforms the ringing message into XMPP syntax.
907 Example 8: XMPP transformation of SIP 180 Ringing message (F7)
909 |
913 |
917 |
918 |
919 |
921 The initiator returns an IQ-result acknowledging receipt of the
922 ringing message, which is used only by the gateway and not
923 transformed into SIP syntax.
925 Example 9: XMPP entity acknowledges ringing message (F8)
927 |
932 The responder sends a SIP 200 OK to the initiator in order to accept
933 the session initiation request.
935 Example 10: SIP user accepts session request (F9)
937 | SIP/2.0 200 OK
938 | Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
939 | received=192.0.2.101
940 | From: Juliet Capulet ;tag=t3hr0zny
941 | To: Romeo Montague ;tag=v3rsch1kk3l1jk
942 | Call-ID: 3848276298220188511@example.com
943 | CSeq: 1 INVITE
944 | Contact:
945 | Content-Type: application/sdp
946 | Content-Length: 147
947 |
948 | v=0
949 | o=romeo 2890844527 2890844527 IN IP4 client.example.net
950 | s=-
951 | c=IN IP4 192.0.2.201
952 | t=0 0
953 | m=audio 3456 RTP/AVP 97
954 | a=rtpmap:97 speex/8000
955 The gateway transforms the 200 OK into a Jingle session-accept
956 action.
958 Example 11: XMPP transformation of SIP 200 OK (F11)
960 |
964 |
969 |
972 |
973 |
974 |
975 |
976 |
978 |
979 |
980 |
981 |
983 If the payload types and transport candidate can be successfully used
984 by both parties, then the initiator acknowledges the session-accept
985 action.
987 Example 12: XMPP user acknowledges session-accept (F12)
989 |
994 The parties now begin to exchange media. In this case they would
995 exchange audio using the Speex codec at a clockrate of 8000 since
996 that is the highest-priority codec for the responder (as determined
997 by the XML order of the children).
999 The parties can continue the session as long as desired.
1001 Eventually, one of the parties (in this case the responder)
1002 terminates the session.
1004 Example 13: SIP user ends session (F15)
1006 | BYE sip:juliet@client.example.com SIP/2.0
1007 | Via: SIP/2.0/TCP client.example.net:5060;branch=z9hG4bKnashds7
1008 | Max-Forwards: 70
1009 | From: Romeo Montague ;tag=8321234356
1010 | To: Juliet Capulet ;tag=9fxced76sl
1011 | Call-ID: 3848276298220188511@example.com
1012 | CSeq: 4 BYE
1013 | Content-Length: 0
1015 The gateway transforms the SIP BYE into XMPP syntax.
1017 Example 14: XMPP transformation of SIP BYE (F17)
1019 |
1023 |
1027 |
1028 |
1029 |
1030 |
1031 |
1033 The initiator returns an IQ-result acknowledging receipt of the
1034 session termination, which is used only by the gateway and not
1035 transformed into SIP syntax.
1037 Example 15: XMPP user acknowledges end of session (F18)
1039
1044 13. IANA Considerations
1046 This document requests no actions by the IANA.
1048 14. Security Considerations
1050 Detailed security considerations for session management are given for
1051 SIP in [RFC3261] and for XMPP in [XEP-0166] (see also [RFC6120]).
1052 The security considerations provided in [RFC7247] also apply.
1054 The addition of gateways to the security model of media signaling
1055 introduces some new risks. In particular, end-to-end security
1056 properties (especially confidentiality and integrity) between media
1057 endpoints that interface through a gateway can be provided only if
1058 common formats are supported. Specification of those common formats
1059 is out of scope for this document and, unfortunately, no generalized
1060 method for end-to-end encryption of signaling messages has yet been
1061 defined, even outside of recognized standards development
1062 organizations (e.g., [RFC3862] and [RFC3923] are not widely
1063 implemented and Off-the-Record Messaging [OTR] can handle only human-
1064 readable chat messages, not structured signaling payloads).
1066 15. References
1068 15.1. Normative References
1070 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1071 Requirement Levels", BCP 14, RFC 2119, March 1997.
1073 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1074 A., Peterson, J., Sparks, R., Handley, M., and E.
1075 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1076 June 2002.
1078 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
1079 Video Conferences with Minimal Control", STD 65, RFC 3551,
1080 July 2003.
1082 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
1083 Norrman, "The Secure Real-time Transport Protocol (SRTP)",
1084 RFC 3711, March 2004.
1086 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1087 Description Protocol", RFC 4566, July 2006.
1089 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
1090 Digits, Telephony Tones, and Telephony Signals", RFC 4733,
1091 December 2006.
1093 [RFC4855] Casner, S., "Media Type Registration of RTP Payload
1094 Formats", RFC 4855, February 2007.
1096 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
1097 (ICE): A Protocol for Network Address Translator (NAT)
1098 Traversal for Offer/Answer Protocols", RFC 5245, April
1099 2010.
1101 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1102 Protocol (XMPP): Core", RFC 6120, March 2011.
1104 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand,
1105 "Interworking between the Session Initiation Protocol
1106 (SIP) and the Extensible Messaging and Presence Protocol
1107 (XMPP): Architecture, Addresses, and Error Handling", RFC
1108 7247, May 2014.
1110 [XEP-0030]
1111 Hildebrand, J., Eatmon, R., and P. Saint-Andre, "Service
1112 Discovery", XSF XEP 0030, June 2008.
1114 [XEP-0166]
1115 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan,
1116 S., and J. Hildebrand, "Jingle", XSF XEP 0166, June 2007.
1118 [XEP-0167]
1119 Ludwig, S., Saint-Andre, P., Egan, S., and R. McQueen,
1120 "Jingle RTP Sessions", XSF XEP 0167, February 2009.
1122 [XEP-0176]
1123 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., and
1124 S. Egan, "Jingle ICE-UDP Transport Method", XSF XEP 0176,
1125 February 2009.
1127 [XEP-0177]
1128 Beda, J., Saint-Andre, P., Ludwig, S., Hildebrand, J., and
1129 S. Egan, "Jingle Raw UDP Transport", XSF XEP 0177,
1130 February 2009.
1132 15.2. Informative References
1134 [I-D.ietf-mmusic-trickle-ice-sip]
1135 Ivov, E., Marocco, E., and C. Holmberg, "A Session
1136 Initiation Protocol (SIP) usage for Trickle ICE", draft-
1137 ietf-mmusic-trickle-ice-sip-02 (work in progress), July
1138 2015.
1140 [I-D.ietf-mmusic-trickle-ice]
1141 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
1142 Incremental Provisioning of Candidates for the Interactive
1143 Connectivity Establishment (ICE) Protocol", draft-ietf-
1144 mmusic-trickle-ice-02 (work in progress), January 2015.
1146 [OTR] Ian Goldberg, , "Off-the-Record Messaging", .
1149 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
1150 August 1980.
1152 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
1153 793, September 1981.
1155 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
1156 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
1157 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
1158 September 1997.
1160 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
1161 with Session Description Protocol (SDP)", RFC 3264, June
1162 2002.
1164 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
1165 Jacobson, "RTP: A Transport Protocol for Real-Time
1166 Applications", STD 64, RFC 3550, July 2003.
1168 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
1169 Payload Formats", RFC 3555, July 2003.
1171 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
1172 Messaging (CPIM): Message Format", RFC 3862, August 2004.
1174 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
1175 for the Extensible Messaging and Presence Protocol
1176 (XMPP)", RFC 3923, October 2004.
1178 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the
1179 Session Initiation Protocol (SIP)", RFC 3959, December
1180 2004.
1182 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
1183 Tone Generation in the Session Initiation Protocol (SIP)",
1184 RFC 3960, December 2004.
1186 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
1187 "Extended RTP Profile for Real-time Transport Control
1188 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
1189 2006.
1191 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in
1192 the RTP Profile for Audio and Video Conferences", RFC
1193 4856, DOI 10.17487/RFC4856, February 2007,
1194 .
1196 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
1197 Real-time Transport Control Protocol (RTCP)-Based Feedback
1198 (RTP/SAVPF)", RFC 5124, February 2008.
1200 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S.,
1201 and P. Kyzivat, "A Session Description Protocol (SDP)
1202 Offer/Answer Mechanism to Enable File Transfer", RFC 5547,
1203 May 2009.
1205 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
1206 Relays around NAT (TURN): Relay Extensions to Session
1207 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
1209 [RFC5768] Rosenberg, J., "Indicating Support for Interactive
1210 Connectivity Establishment (ICE) in the Session Initiation
1211 Protocol (SIP)", RFC 5768, April 2010.
1213 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
1214 Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
1216 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX:
1217 Combined Use of the Session Initiation Protocol (SIP) and
1218 the Extensible Messaging and Presence Protocol (XMPP)",
1219 RFC 7081, November 2013.
1221 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
1222 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
1223 2014.
1225 [RFC7395] Stout, L., Moffitt, J., and E. Cestari, "An Extensible
1226 Messaging and Presence Protocol (XMPP) Subprotocol for
1227 WebSocket", RFC 7395, October 2014.
1229 [XEP-0124]
1230 Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., and
1231 L. Stout, "Bidirectional-streams Over Synchronous HTTP
1232 (BOSH)", XSF XEP 0124, November 2013.
1234 [XEP-0234]
1235 Saint-Andre, P., "Jingle File Transfer", XSF XEP 0234,
1236 August 2014.
1238 [XEP-0269]
1239 Cionoiu, D. and P. Saint-Andre, "Jingle Early Media", XSF
1240 XEP 0269, May 2009.
1242 Appendix A. Acknowledgements
1244 Thanks to Dave Crocker, Philipp Hancke, Paul Kyzivat, and Jonathan
1245 Lennox for their feedback. Jonathan in particular provided helpful
1246 suggestions regarding the transport fallback section.
1248 The authors gratefully acknowledge the assistance of Markus Isomaki
1249 and Yana Stamcheva as the working group chairs and Ben Campbell as
1250 the sponsoring Area Director.
1252 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
1253 employing him during his work on earlier draft versions of this
1254 document.
1256 Authors' Addresses
1258 Peter Saint-Andre
1259 &yet
1261 Email: peter@andyet.com
1262 URI: https://andyet.com/
1264 Saul Ibarra Corretge
1265 AG Projects
1266 Dr. Leijdsstraat 92
1267 Haarlem 2021RK
1268 The Netherlands
1270 Email: saul@ag-projects.com
1272 Emil Ivov
1273 Jitsi
1274 Strasbourg 67000
1275 France
1277 Phone: +33-177-624-330
1278 Email: emcho@jitsi.org