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