idnits 2.17.00 (12 Aug 2021) /tmp/idnits22250/draft-saintandre-sip-xmpp-media-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 4822 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 ** Obsolete normative reference: RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) == Outdated reference: A later version (-05) exists of draft-saintandre-sip-xmpp-core-01 ** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Cisco 4 Intended status: Informational March 8, 2009 5 Expires: September 9, 2009 7 Interworking between the Session Initiation Protocol (SIP) and the 8 Extensible Messaging and Presence Protocol (XMPP): Media Sessions 9 draft-saintandre-sip-xmpp-media-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 9, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines a bi-directional protocol mapping for use by 48 gateways that enable the exchange of media signalling messages 49 between systems that implement the Jingle extensions to the 50 Extensible Messaging and Presence Protocol (XMPP) and those that 51 implement the Session Initiation Protocol (SIP). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Jingle to SIP . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Syntax Mappings . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Sample Scenarios . . . . . . . . . . . . . . . . . . . . . 8 60 3. SIP to Jingle . . . . . . . . . . . . . . . . . . . . . . . . 14 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 15 64 5.2. Informative References . . . . . . . . . . . . . . . . . . 16 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 1. Introduction 69 The Session Initiation Protocol [SIP] is a widely-deployed technology 70 for the management of media sessions (such as voice calls) over the 71 Internet. SIP itself provides a signalling channel (typically via 72 the User Datagram Protocol [UDP]), over which two or more parties can 73 exchange messages for the purpose of negotiating a media session that 74 uses a dedicated media channel such as the Real-time Transport 75 Protocol [RTP]. 77 The Extensible Messaging and Presence Protocol [XMPP] also provides a 78 signalling channel, typically via the Transmission Control Protocol 79 [TCP]. Given the significant differences between XMPP and SIP, it is 80 difficult to combine the two technologies in a single user agent. 81 Therefore, developers wishing to add media session capabilities to 82 XMPP clients have defined an XMPP-specific negotiation protocol 83 called Jingle [JINGLE]. 85 However, Jingle has been designed to easily map to SIP for 86 communication through gateways or other transformation mechanisms. 87 Therefore, consistent with existing specifications for mapping 88 between SIP and XMPP (see [SIP-XMPP] and other specifications in that 89 "series"), this document describes a bi-directional protocol mapping 90 for use by gateways that enable the exchange of media signalling 91 messages between systems that implement SIP and those that implement 92 the XMPP Jingle extensions. 94 Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", 95 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 96 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 97 interpreted as described in RFC 2119 [TERMS]. 99 2. Jingle to SIP 101 2.1. Overview 103 As mentioned, Jingle was designed in part to enable straightforward 104 protocol mapping between XMPP and SIP. However, given the 105 significantly different technology assumptions underlying XMPP and 106 SIP, Jingle is naturally different from SIP in several important 107 respects: 109 o Base SIP messages and headers use a plaintext format similar in 110 some ways to the Hypertext Transport Protocol [HTTP], whereas 111 Jingle messages are pure XML. Mappings between SIP headers and 112 Jingle message syntax are provided below. 114 o The SIP payloads defining session semantics use the Session 115 Description Protocol [SDP], whereas the equivalent Jingle payloads 116 are defined as XML child elements of the Jingle 117 element. However, the Jingle specifications defining such child 118 elements specify mappings to SDP for all Jingle syntax, making the 119 mapping relatively straightforward. 120 o The SIP signalling channel is transported over UDP, whereas the 121 signalling channel for Jingle is XMPP over TCP. Mapping between 122 the transport layers typically happens within a gateway using 123 techniques below the application level, and therefore is not 124 addressed in this specification. 126 2.2. Syntax Mappings 128 2.2.1. Generic Jingle Syntax 130 Jingle is designed in a modular fashion, so that session description 131 data is generally carried in a payload within the generic Jingle 132 elements, i.e., the element and its child. The 133 following example illustrates this structure, where the XMPP stanza 134 is a request to initiate an audio session using RTP over a raw UDP 135 transport. 137 141 145 149 150 151 152 153 157 158 159 160 161 162 163 164 166 In the foregoing example, the syntax and semantics of the 167 and elements are defined in [JINGLE], the syntax and 168 semantics of the element are defined in [JINGLE-RTP], 169 and the syntax and semantics of the element are defined 170 in [JINGLE-UDP]. Other elements are defined in 171 specifications for the appropriate application types (see for example 172 [JINGLE-RTP]) and other elements are defined in the 173 specifications for appropriate transport methods (see for example 174 [JINGLE-ICE], which defines an XMPP profile of [ICE]). 176 At the core Jingle layer, the following mappings are defined. 178 +--------------------------------+--------------------------------+ 179 | Jingle | SIP | 180 +--------------------------------+--------------------------------+ 181 | 'action' | [ see next table ] | 182 +--------------------------------+--------------------------------+ 183 | 'initiator' | [ no mapping ] | 184 +--------------------------------+--------------------------------+ 185 | 'responder' | [ no mapping ] | 186 +--------------------------------+--------------------------------+ 187 | 'sid' | local-part of Call-ID | 188 +--------------------------------+--------------------------------+ 189 | local-part of 'initiator' | in SDP o= line | 190 +--------------------------------+--------------------------------+ 191 | 'creator' | [ no mapping ] | 192 +--------------------------------+--------------------------------+ 193 | 'name' | [ no mapping ] | 194 +--------------------------------+--------------------------------+ 195 | 'profile' | in SDP m= line | 196 +--------------------------------+--------------------------------+ 197 | 'senders' value of | a= line of sendrecv, recvonly, | 198 | both, initiator, or responder | or sendonly | 199 +--------------------------------+--------------------------------+ 201 The 'action' attribute of the element has nine allowable 202 values. In general they should be mapped as shown in the following 203 table, with some exceptions as described herein. 205 +-------------------+-----------------+ 206 | Jingle Action | SIP Method | 207 +-------------------+-----------------+ 208 | content-accept | INVITE response | 209 | | (1xx) | 210 +-------------------+-----------------+ 211 | content-add | INVITE request | 212 +-------------------+-----------------+ 213 | content-modify | INVITE request | 214 +-------------------+-----------------+ 215 | content-remove | INVITE request | 216 +-------------------+-----------------+ 217 | session-accept | INVITE response | 218 | | (1xx or 2xx) | 219 +-------------------+-----------------+ 220 | session-info | [varies] | 221 +-------------------+-----------------+ 222 | session-initiate | INVITE request | 223 +-------------------+-----------------+ 224 | session-terminate | BYE | 225 +-------------------+-----------------+ 226 | transport-info | [varies] | 227 +-------------------+-----------------+ 229 2.2.2. Audio Application Format 231 A Jingle application format for audio exchange via RTP is specified 232 in [JINGLE-RTP]. This application format effectively maps to the 233 "RTP/AVP" profile specified in [RTP-AVP], where the media type is 234 "audio" and the specific mappings to SDP syntax are provided in 235 [JINGLE-RTP]. 237 2.2.3. Video Application Format 239 A Jingle application format for video exchange via RTP is specified 240 in [JINGLE-RTP]. This application format effectively maps to the 241 "RTP/AVP" profile specified in [RTP-AVP], where the media type is 242 "audio" and the specific mappings to SDP syntax are provided in 243 [JINGLE-RTP]. 245 2.2.4. Raw UDP Transport Method 247 A basic Jingle transport method for exchanging media over UDP is 248 specified in [JINGLE-UDP]. This transport method involves the 249 negotiation of an IP address and port only, and does not provide NAT 250 traversal. The Jingle 'ip' attribute maps to the connection-address 251 parameter of the SDP c= line and the 'port' attribute maps to the 252 port parameter of the SDP m= line. 254 2.2.5. ICE-UDP Transport Method 256 A more advanced Jingle transport method for exchanging media over UDP 257 is specified in [JINGLE-ICE]. Under ideal conditions this transport 258 method provides NAT traversal by following the Interactive 259 Connectivity Exchange methodology specified in [ICE]. The relevant 260 SDP mappings are provided in [JINGLE-ICE]. 262 2.3. Sample Scenarios 264 The following sections provide sample scenarios (or "call flows") 265 that illustrate the principles of interworking from Jingle to SIP. 266 These scenarios are not exhaustive. 268 2.3.1. Basic Voice Chat 270 The protocol flow for a basic voice chat for which an XMPP user 271 (juliet@example.com) is the iniator and a SIP user 272 (romeo@example.net) is the responder. The voice chat is consummated 273 through a gateway. To simplify the example, the transport method 274 negotiated is "raw user datagram protocol" as specified in 275 [JINGLE-UDP]. 277 INITIATOR ...XMPP... GATEWAY ...SIP... RESPONDER 278 | | | 279 | session-initiate | | 280 |----------------------->| | 281 | IQ-result (ack) | | 282 |<-----------------------| | 283 | | INVITE | 284 | |---------------------->| 285 | | 180 Ringing | 286 | |<----------------------| 287 | session-info (ringing) | | 288 |<-----------------------| | 289 | IQ-result (ack) | | 290 |----------------------->| | 291 | | 200 OK | 292 | |<----------------------| 293 | session-accept | | 294 |<-----------------------| | 295 | IQ-result (ack) | | 296 |----------------------->| | 297 | | ACK | 298 | |---------------------->| 299 | MEDIA SESSION | 300 |<==============================================>| 301 | | BYE | 302 | |<----------------------| 303 | session-terminate | | 304 |<-----------------------| | 305 | IQ-result (ack) | | 306 |----------------------->| | 307 | | 200 OK | 308 | |---------------------->| 309 | | | 311 The packet flow is as follows. 313 First the XMPP user sends a Jingle session-initiation request to the 314 SIP user. 316 320 324 327 328 329 330 331 332 333 334 335 336 337 339 The gateway returns an XMPP IQ-result to the initiator on behalf of 340 the responder. 342 347 The gateway transforms the Jingle session-initiate action into a SIP 348 INVITE. 350 INVITE sip:romeo@example.net SIP/2.0 351 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9 352 Max-Forwards: 70 353 From: Juliet Capulet ;tag=t3hr0zny 354 To: Romeo Montague 355 Call-ID: 3848276298220188511@example.com 356 CSeq: 1 INVITE 357 Contact: 358 Content-Type: application/sdp 359 Content-Length: 184 361 v=0 362 o=alice 2890844526 2890844526 IN IP4 client.example.com 363 s=- 364 c=IN IP4 192.0.2.101 365 t=0 0 366 m=audio 49172 RTP/AVP 0 367 a=rtpmap:96 SPEEX/16000 368 a=rtpmap:97 SPEEX/8000 369 a=rtpmap:18 G729 371 The responder returns a SIP 180 Ringing message. 373 SIP/2.0 180 Ringing 374 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9 375 ;received=192.0.2.101 376 From: Juliet Capulet ;tag=t3hr0zny 377 To: Romeo Montague ;tag=v3rsch1kk3l1jk 378 Call-ID: 3848276298220188511@example.com 379 CSeq: 1 INVITE 380 Contact: 381 Content-Length: 0 383 The gateway transforms the ringing message into XMPP syntax. 385 389 393 394 395 397 The initiator returns an IQ-result acknowledging receipt of the 398 ringing message, which is used only by the gateway and not 399 transformed into SIP syntax. 401 406 The responder sends a SIP 200 OK to the initiator. 408 SIP/2.0 200 OK 409 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9 410 ;received=192.0.2.101 411 From: Juliet Capulet ;tag=t3hr0zny 412 To: Romeo Montague ;tag=v3rsch1kk3l1jk 413 Call-ID: 3848276298220188511@example.com 414 CSeq: 1 INVITE 415 Contact: 416 Content-Type: application/sdp 417 Content-Length: 147 419 v=0 420 o=romeo 2890844527 2890844527 IN IP4 client.example.net 421 s=- 422 c=IN IP4 192.0.2.201 423 t=0 0 424 m=audio 3456 RTP/AVP 0 425 a=rtpmap:97 SPEEX/8000 426 a=rtpmap:18 G729/8000 428 The gateway transforms the 200 OK into a Jingle session-accept 429 action. 431 435 440 443 444 445 446 447 448 449 450 451 452 453 455 If the payload types and transport candidate can be successfully used 456 by both parties, then the initiator acknowledges the session-accept 457 action. 459 464 The parties now begin to exchange media. In this case they would 465 exchange audio using the Speex codec at a clockrate of 8000 since 466 that is the highest-priority codec for the responder (as determined 467 by the XML order of the children). 469 The parties may continue the session as long as desired. 471 Eventually, one of the parties (in this case the responder) 472 terminates the session. 474 BYE sip:juliet@client.example.com SIP/2.0 475 Via: SIP/2.0/TCP client.example.net:5060;branch=z9hG4bKnashds7 476 Max-Forwards: 70 477 From: Romeo Montague ;tag=8321234356 478 To: Juliet Capulet ;tag=9fxced76sl 479 Call-ID: 3848276298220188511@example.com 480 CSeq: 1 BYE 481 Content-Length: 0 483 The gateway transforms the SIP BYE into XMPP syntax. 485 489 494 496 The initiator returns an IQ-result acknowledging receipt of the 497 session termination, which is used only by the gateway and not 498 transformed into SIP syntax. 500 505 3. SIP to Jingle 507 To follow. 509 4. Security Considerations 511 Detailed security considerations for session management are given for 512 SIP in [SIP] and for XMPP in [JINGLE] (see also [XMPP]). 514 5. References 515 5.1. Normative References 517 [ICE] Rosenberg, J., "Interactive Connectivity Establishment 518 (ICE): A Protocol for Network Address Translator (NAT) 519 Traversal for Offer/Answer Protocols", 520 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 522 [JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 523 S., and J. Hildebrand, "Jingle", XSF XEP 0166, June 2007. 525 [JINGLE-RTP] 526 Ludwig, S., Saint-Andre, P., Egan, S., and R. McQueen, 527 "Jingle RTP Sessions", XSF XEP 0167, February 2009. 529 [JINGLE-ICE] 530 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., and 531 S. Egan, "Jingle ICE-UDP Transport Method", XSF XEP 0176, 532 February 2009. 534 [JINGLE-UDP] 535 Beda, J., Saint-Andre, P., Ludwig, S., Hildebrand, J., and 536 S. Egan, "Jingle Raw UDP Transport", XSF XEP 0177, 537 February 2009. 539 [RTP-AVP] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 540 Video Conferences with Minimal Control", STD 65, RFC 3551, 541 July 2003. 543 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 544 Description Protocol", RFC 4566, July 2006. 546 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 547 A., Peterson, J., Sparks, R., Handley, M., and E. 548 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 549 June 2002. 551 [SIP-XMPP] 552 Saint-Andre, P., Houri, A., and J. Hildebrand, 553 "Interworking between the Session Initiation Protocol 554 (SIP) and the Extensible Messaging and Presence Protocol 555 (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in 556 progress), March 2009. 558 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 562 Protocol (XMPP): Core", RFC 3920, October 2004. 564 5.2. Informative References 566 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 567 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 568 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 570 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 571 Jacobson, "RTP: A Transport Protocol for Real-Time 572 Applications", STD 64, RFC 3550, July 2003. 574 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 575 RFC 793, September 1981. 577 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 578 August 1980. 580 Author's Address 582 Peter Saint-Andre 583 Cisco 585 Email: psaintan@cisco.com