idnits 2.17.1 draft-jennings-rtcweb-signaling-gateway-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 24, 2011) is 4565 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) == Unused Reference: 'RFC2119' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 616, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft S. Nandakumar 4 Intended status: Standards Track Cisco 5 Expires: April 26, 2012 C. Holmberg 6 Ericsson 7 October 24, 2011 9 SIP to RTCWeb Offer/Answer Protocol (ROAP) Gateway 10 draft-jennings-rtcweb-signaling-gateway-00 12 Abstract 14 This document proposes behavior of a RTCWeb signaling gateway for 15 mapping message representations between RTCWeb Offer/Answer Protocol 16 (ROAP) scheme and native SIP messaging scheme. Such a signaling 17 gateway is intended to translate to and from/SIP for enabling use 18 cases between a RTCWeb enabled browser and legacy SIP devices. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 26, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Mapping to SIP . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. SuccessFull Session Establishment . . . . . . . . . . . . 3 57 2.2. Add New Media (video) . . . . . . . . . . . . . . . . . . 8 58 2.3. SuccessFull Session Ending . . . . . . . . . . . . . . . . 11 59 3. Handling SIP Requests . . . . . . . . . . . . . . . . . . . . 12 60 4. Handling SIP Responses . . . . . . . . . . . . . . . . . . . . 13 61 5. Handling Web Messages . . . . . . . . . . . . . . . . . . . . 14 62 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 This specification suggests one possible way to build a RTCWeb 74 Signaling gateway that maps message representations proposed in 75 [ROAP] to native SIP [RFC3261] messages and vice-versa. The 76 specification [ROAP] describes a signaling protocol for RTCWeb to 77 support negotiation of media session using SDP offer/answer [RFC3264] 78 protocol. Such a signaling protocol enables an RTCWeb browser to 79 setup media sessions to another browser or a SIP device. For 80 Browser-to-SIP device use case, the signaling gateway connects to 81 legacy SIP devices and SHALL translate messages between ROAP and SIP 82 native messages schemes. 84 2. Mapping to SIP 86 Note: The SDP and SIP examples are not correct but illustrate the 87 rough outline of the mechanism. Future version will correct this. 89 The design requires the gateway to be SIP transaction statefull but 90 does not require any storage of longer term state. The information 91 that remains constant over the SIP dialog is stored in session tokens 92 while the information that is needed to from a SIP response is stored 93 in response tokens. The gateway appears as a SIP UA to the sip side. 94 Message on the two sides of the signalling gateway are referred to as 95 the SIP side and web side. 97 The following sub-sections show example message flows with detailed 98 message description of native SIP messages that are mapped from ROAP 99 scheme and the ones that are received as responses by the signaling 100 gateway. CallerUA(callerua@atlanta.example.com) is a RTCWeb browser. 101 CalleeUA(sip:calleeua@sippy.example.com) is assumed to be a SIP- 102 enabled device. It is also assumed that CalleeUA has registered with 103 a SIP proxy server to be able to receive the calls via the proxy. 105 2.1. SuccessFull Session Establishment 107 In this scenario CallerUA establishes successful media session with 108 CalleeUA, a legacy SIP end-point, with the help of the RTCWeb 109 signaling gateway. 111 participant CallerUA 112 participant CallerJS 113 participant SIPGW 114 participant CalleeUA 116 CallerJS->CallerUA: peer=new PeerConnection(); 118 CallerJS->CallerUA: peer->addStream(); 119 CallerUA->CallerJS: sendSignalingChannel(); 120 CallerJS->SIPGW: {"type":"OFFER", "sdp":"..."} 121 SIPGW->CalleeUA: SIP INVITE 122 note right of CalleeUA: Alert user 124 CalleeUA->CallerUA: ICE Checking 126 CalleeUA->SIPGW: SIP 180 w/SDP 127 SIPGW->CallerJS: {"type":"ANSWER", "more-coming":"TRUE", "sdp":"..."} 128 note right of CallerJS: This SDP has ICE candidates 129 CallerJS->CallerUA: peer->processSignalingMessage(); 130 CallerUA->CallerJS: onstatechange(); 131 note left of CallerUA: Might have one way\nmedia flowing at this point 133 CallerUA->CalleeUA: More ICE checking 134 CalleeUA->CallerUA: ICE Completes 135 CallerUA->CallerJS: onopen(); 137 CalleeUA->SIPGW: SIP 200 138 SIPGW->CallerJS: {"type":"ANSWER", "sdp":"..."} 139 CallerJS->CallerUA: peer->processSignalingMessage(); 140 CallerUA->CallerJS: onopen(); 142 CalleeUA->CallerUA: Two-way Media 143 note right of CalleeUA: Media plays 145 CallerUA->CallerJS: sendSignalingChannel(); 146 CallerJS->SIPGW: {"type":"OK" } 147 SIPGW->CalleeUA: SIP ACK 149 Message Details 151 Signaling gateway (on behalf of CallerUA) maps ROAP:OFFER (section 152 5.3.1 of ROAP[ROAP]) to SIP:INVITE and sends it to CalleeUA to start 153 the session. 155 {"type":"OFFER", 156 "offererSessionId":"36707f69b", 157 "seq": 1 158 "sdp":" 159 v=0 160 o=callerua 1429 0 IN IP4 client.atlanta.example.com 161 s=Call 162 c=IN IP4 192.0.2.101 163 t=0 0 164 m=audio 16384 RTP/AVP 0 165 a=rtpmap:0 PCMU/8000 166 a=sendrecv" 167 } 169 {INVITE sip:calleeua@sippy.example.com SIP/2.0 170 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 171 Max-Forwards: 70 172 From: CallerUA ;tag=36707f69b 173 To: CalleeUA 174 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 175 CSeq: 1 INVITE 176 Contact: 177 Content-Type: application/sdp 179 v=0 180 o=callerua 1429 0 IN IP4 client.atlanta.example.com 181 s=Call 182 c=IN IP4 192.0.2.101 183 t=0 0 184 m=audio 16384 RTP/AVP 0 185 a=rtpmap:0 PCMU/8000 186 a=sendrecv 187 } 189 SIP:180 from CalleeUA is received at the signaling gateway. 191 {SIP/2.0 180 Ringing 192 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 193 ;received=192.0.2.101 194 From: CallerUA ;tag=36707f69b 195 To: CalleeUA ;tag=8321234356 196 Call-ID:00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 197 CSeq: 1 INVITE 198 Contact: 200 v=0 201 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com 202 s=Call 203 c=IN IP4 192.0.2.201 204 t=0 0 205 m=audio 16834 RTP/AVP 0 206 a=rtpmap:0 PCMU/8000 207 a=sendrecv 208 } 210 This message SHALL be converted to ROAP:Answer (section 5.3.2 of 211 ROAP[ROAP]) with "more-coming" flag set to true as described in the 212 section 5.2.3 of ROAP[ROAP] specification and sent to CallerUA by the 213 signaling gateway. 215 {"type":"ANSWER", 216 "offererSessionId":"36707f69b", 217 "answererSessionId":"8321234356", 218 "seq": 1, 219 "more-coming": true, 220 "sdp":" 221 v=0 222 o=callerua 1429 0 IN IP4 client.atlanta.example.com 223 s=Call 224 c=IN IP4 192.0.2.101 225 t=0 0 226 m=audio 16384 RTP/AVP 0 227 a=rtpmap:0 PCMU/8000 228 a=sendrecv" 229 } 231 SIP: OK from CalleeUA is received at the signaling gateway. 233 {SIP/2.0 200 OK 234 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 235 ;received=192.0.2.101 236 From: CallerUA ;tag=36707f69b 237 To: CalleeUA ;tag=8321234356 238 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 239 CSeq: 1 INVITE 240 Contact: 241 Content-Type: application/sdp 243 v=0 244 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com 245 s=Call 246 c=IN IP4 192.0.2.201 247 t=0 0 248 m=audio 16834 RTP/AVP 0 249 a=rtpmap:0 PCMU/8000 250 a=sendrecv 251 } 253 This message SHALL be converted to ROAP:Answer(section 5.3.2 of 254 ROAP[ROAP]) and sent to caller by the signaling gateway. This 255 represents a final answer as described in the section 5.2.3 of 256 ROAP[ROAP] 258 {"type":"ANSWER", 259 "offererSessionId":"36707f69b", 260 "answererSessionId":"8321234356", 261 "seq": 1, 262 "sdp":" 263 v=0 264 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com 265 s=Call 266 c=IN IP4 192.0.2.201 267 t=0 0 268 m=audio 16834 RTP/AVP 0 269 a=rtpmap:0 PCMU/8000 270 a=sendrecv" 271 } 273 Signaling gateway (on behalf of CallerUA) maps ROAP:OK (section 5.3.2 274 of ROAP[ROAP]) to SIP:ACK and sends it to CalleeUA to start the 275 session. This completes call-setup and media streams are established 276 between CallerUA and the CalleeUA. 278 {"type":"OK", 279 "offererSessionId":"36707f69b", 280 "answererSessionId":"8321234356", 281 "seq": 1 282 } 284 {ACK sip:calleeua@client.sippy.example.com SIP/2.0 285 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 286 Max-Forwards: 70 287 From: CallerUA ;tag=36707f69b 288 To: CalleeUA ;tag=8321234356 289 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 290 CSeq: 1 ACK 291 } 293 2.2. Add New Media (video) 295 This scenario describes the message exchanges when CalleeUA decides 296 to add video as media to an existing audio-only session 298 participant CallerUA 299 participant CallerJS 300 participant SIPGW 301 participant CalleeUA 303 CalleeUA->CallerUA: Two-way Media (audio only) 304 note right of CalleeUA: Media plays 306 note right of CalleeUA: Callee decides to add video 308 CalleeUA->SIPGW: SIP ReINVITE 309 SIPGW->CallerJS: {"type":"OFFER", "sdp":"..."} 310 CallerJS->CallerUA: peer->processSignalingMessage(); 312 CallerUA->CallerJS: sendSignalingChannel(); 313 CallerJS->SIPGW: {"type":"ANSWER", "sdp":"..."} 314 SIPGW->CalleeUA: SIP 200 316 CalleeUA->SIPGW: SIP ACK 317 SIPGW->CallerJS: {"type":"OK" } 318 CallerJS->CallerUA: peer->processSignalingMessage(); 319 CallerUA->CallerJS: onaddstream(); 321 CalleeUA->CallerUA: Two-way Media 322 note right of CalleeUA: Media plays with video 323 Message Details 325 On receipt of SIP:INVITE with SDP for video, the signaling gateway 326 maps SIP:INVITE to ROAP:OFFER(section 5.3.1 of ROAP[ROAP]) and sends 327 it to CallerUA indicating the intent. 329 {INVITE sip:callerua@atlanta.example.com SIP/2.0 330 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 331 Max-Forwards: 70 332 From: CalleeUA ;tag=8321234356 333 To: CallerUA ;tag=36707f69b 334 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 335 CSeq: 2 INVITE 336 Contact: 337 Content-Type: application/sdp 339 v=0 340 o=callerua 1429 0 IN IP4 client.atlanta.example.com 341 s=SIP Call 342 c=IN IP4 192.0.2.101 343 t=0 0 344 m=video 1024 RTP/AVP 97 345 a=fmtp:97 profile-level-id=42E00C 346 a=sendrecv 347 } 349 CallerUA accepts the new ROAP:OFFER(section 5.3.1 of ROAP[ROAP]) and 350 sends ROAP:ANSWER section 5.3.2 of ROAP[ROAP]). 352 {"type":"OFFER", 353 "offererSessionId":"36707f69b", 354 "answererSessionId":"8321234356", 355 "seq": 2, 356 "sdp":" 357 v=0 358 o=callerua 1429 0 IN IP4 client.atlanta.example.com 359 s=Call 360 c=IN IP4 192.0.2.101 361 t=0 0 362 m=video 1024 RTP/AVP 97 363 a=fmtp:97 profile-level-id=42E00C 364 a=sendrecv" 365 } 367 Which results in the follwing answer. 369 {"type":"ANSWER", 370 "offererSessionId":"36707f69b", 371 "answererSessionId":"8321234356", 372 "seq": 2, 373 "sdp":" 374 v=0 375 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com 376 s=Call 377 c=IN IP4 192.0.2.201 378 t=0 0 379 m=audio 16834 RTP/AVP 0 380 a=rtpmap:0 PCMU/8000 381 a=sendrecv" 382 } 384 The signaling gateway maps the ROAP:ANSWER to SIP:200 to be sent to 385 the CalleeUA. 387 { 388 {SIP/2.0 200 OK 389 Via: SIP/2.0/UDP client.sippy.example.com:5060;branch=z9hG4bK74bf9 390 ;received=192.0.2.201 391 From: CalleeUA ;tag=8321234356 392 To: CallerUA ;tag=36707f69b 393 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 394 CSeq: 102 INVITE 395 Contact: 396 Content-Type: application/sdp 398 v=0 399 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com 400 s=SIP Call 401 c=IN IP4 192.0.2.201 402 t=0 0 403 m=video 1024 RTP/AVP 97 404 a=fmtp:97 profile-level-id=42E00C 405 a=sendrecv 406 } 408 CalleeUA accepts the receipt of SIP:200 by sending SIP:ACK. The 409 signaling gateway SIP:ACK to ROAP:OK (section 5.3.2 of ROAP[ROAP]) 410 sends it to CallerUA. This completes adding the new media (video) to 411 the existing session. 413 {ACK sip:callerua@client.atlanta.example.com SIP/2.0 414 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 415 Max-Forwards: 70 416 From: calleeua ;tag=8321234356 417 To: callerua ;tag=36707f69b 418 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 419 CSeq: 2 ACK 420 } 422 {"type":"OK", 423 "offererSessionId":"36707f69b", 424 "answererSessionId":"8321234356", 425 "seq": 2 426 } 428 2.3. SuccessFull Session Ending 430 This section capture native SIP message descriptions when the caller 431 decides to end the ongoing session. 433 participant CallerUA 434 participant CallerJS 435 participant SIPGW 436 participant CalleeUA 438 CalleeUA->CallerUA: Two-way Media (audio + video) 439 note right of CalleeUA: Media plays 441 note left of CallerUA: Caller decides to end the session 443 CallerJS->CallerUA: peer->close(); 444 CallerUA->CallerJS: sendSignalingChannel(); 445 CallerJS->SIPGW: {"type":"SHUTDOWN"} 446 SIPGW->CalleeUA: SIP BYE 447 CalleeUA->SIPGW: SIP 200 448 SIPGW->CallerJS: {"type":"OK"} 449 CallerJS->CallerUA: peer->processSignalingMessage(); 451 Message Details 453 The signaling gateway maps ROAP:SHUTDOWN message from the CallerUA to 454 SIP:BYE and send it to CalleeUA to end the ongoing session. 456 {"type":"SHUTDOWN", 457 "offererSessionId":"36707f69b", 458 "answererSessionId":"8321234356", 459 "seq": 3 460 } 462 {BYE sip:callerua@client.atlanta.example.com SIP/2.0 463 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 464 Max-Forwards: 70 465 From: CallerUA ;tag=36707f69b 466 To: CalleeUA ;tag=8321234356 467 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 468 CSeq: 3 BYE 469 } 471 CalleeUA end's the session from it's side by sending SIP:OK. 473 {SIP/2.0 200 OK 474 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 475 ;received=192.0.2.101 476 From: CallerUA ;tag=36707f69b 477 To: CalleeUA ;tag=8321234356 478 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com 479 CSeq: 3 BYE 480 Contact: 481 } 483 This message SHALL be converted to ROAP:OK(section 5.3.2 of 484 ROAP[ROAP]) and sent to caller by the signaling gateway. 486 {"type":"OK", 487 "offererSessionId":"36707f69b", 488 "answererSessionId":"8321234356", 489 "seq": 3 490 } 492 3. Handling SIP Requests 494 When the signalling gateway receives a SIP request, the gateway forms 495 the message on the web request side in the following way: 496 1. The SIP methods INVITE, ACK, BYE, CANCEL are mapped to 497 messageType OFFER, OK, SHUTDOWN, SHUTDOWN respectively 498 2. The Seq on web side is formed from the numeric portion of CSeq 499 header field value from the SIP side. 501 3. The offererSessionId is formed by a JSON object string that has 502 an call-id attribute containing the SIP call-id header field 503 value and a from-tag attribute containing the SIP from-tag. 504 4. If there is a SIP to-tag, it is used for the answererSessionId. 505 5. If there is a SIP body containing SDP, it is copied into the SDP 506 parameter on web side. 507 6. The setSessionToken is formed by a JSON object string that has 508 contact attribute that contains the SIP contact header field 509 value and an route attribute which is an array that has the 510 values of the SIP route header field values in reverse order. 511 7. The setResponseToken formed by a JSON object string that has via 512 attribute that is an array containing the SIP via headers field 513 values. The JSON object also includes an attribute that holds 514 the request method. The gateway MAY include any other SIP 515 headers in an attribute named headers which is an array with one 516 header field in each entry. 518 4. Handling SIP Responses 520 When the signalling gateway receives a SIP response, the gateway 521 forms the message on the web request side in the following way: 522 1. The SIP responses 180 is mapped to ANSWER with more_coming. A 523 200 response that contains SDP is mapped to ANSWER. 481 is mapped 524 to NOMATCH. 408 is mapped to TIMEOUT. 486 is mapped to REFUSED. 525 491 is mapped to CONFLICT. All other SIP 3xx to 6xx responses 526 are mapped to FAILED. 527 2. The Seq on web side is formed from the numeric portion of CSeq 528 header field value from the SIP side. 529 3. The offererSessionId is formed by a JSON object string that has 530 an call-id attribute containing the SIP call-id header field 531 value and a from-tag attribute containing the SIP from-tag. 532 4. The SIP to-tag is used for the answererSessionId. 533 5. If there is a SIP body containing SDP, it is copied into the SDP 534 parameter on web side. 535 6. The setSessionToken is formed by a JSON object string that has 536 contact attribute that contains the SIP contact header field 537 value and an route attribute which is an array that has the 538 values of the SIP route header field values. 539 7. The setResponseToken formed by a JSON object string that has via 540 attribute that is an array containing the SIP via headers field 541 values. The gateway MAY include any other SIP headers in an 542 attribute named headers which is an array with one header field 543 in each entry. 545 5. Handling Web Messages 547 When the signalling gateway receives a WEB message, the gateway forms 548 the message on the SIP side in the following way: 549 1. The messageType OFFER, ANSWER with more_coming, ANSWER, OK, 550 NOMATCH, TIMEOUT, REFUSED, CONFLICT, FAILED are mapped to 551 INVITE, 180, 200, ACK, 481, 408, 486, 491, 500 respectively. 552 2. The messageType SHUTDOWN is mapped to a CANCEL if the 553 answererSessionId is empty and to BYE otherwise 554 3. For SIP responses, The numeric portion of the CSeq is formed by 555 taking the number portion from the Seq field. If the 556 setResponseToken contains a method name, that is used for the 557 method portion of the CSeq otherwise if it does not exist, the 558 request method of the SIP message is used. 559 4. The Call-ID header field values is formed from the call-id 560 attribute of the offererSessionId. 561 5. The from-tag is formed from the from-tag attribute of the 562 offererSessionId. 563 6. If there is a answererSessionId, it is used for the SIP to-tag. 564 7. If there is a SDP parameter, it is used as a SIP SDP body and 565 the content type of and content length headers are set 566 appropriately. 567 8. If there is a sessionToken that contains a contact attribute, it 568 is used to form the SIP contact header field value. 569 9. If there is a sessionToken that contains a route array, it is 570 used to form the SIP route header field values. 571 10. If there is a responseToken that contains a via array, it is 572 used to form the SIP via header field values. 574 6. Limitations 576 The following things, if used on the SIP side, will not interoperate: 578 o Redirection via 3xx 579 o UPDATE / PRACK 580 o REFER 581 o SIP to pre RFC 3261 devices that don't support to and from tags. 582 o SUB/NOTify 583 o SIP INVITES that do not contain an SDP offer 584 o SIP extensions to RFC 3261. 586 7. Security Considerations 588 TBD 590 8. IANA Considerations 592 This document requires no actions from IANA. 594 9. Acknowledgments 596 598 10. References 600 10.1. Normative References 602 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 603 with Session Description Protocol (SDP)", RFC 3264, 604 June 2002. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 10.2. Informative References 611 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 612 A., Peterson, J., Sparks, R., Handley, M., and E. 613 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 614 June 2002. 616 [I-D.ietf-rtcweb-use-cases-and-requirements] 617 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 618 Time Communication Use-cases and Requirements", 619 draft-ietf-rtcweb-use-cases-and-requirements-06 (work in 620 progress), October 2011. 622 [ROAP] Jennings, C. and J. Rosenberg, "RTCWeb Offer/Answer 623 Protocol (ROAP)", draft-jennings-rtcweb-signaling (work in 624 progress), October 2011. 626 Authors' Addresses 628 Cullen Jennings 629 Cisco 630 170 West Tasman Drive 631 San Jose, CA 95134 632 USA 634 Phone: +1 408 421-9990 635 Email: fluffy@cisco.com 637 Suhas Nandakumar 638 Cisco 639 170 West Tasman Drive 640 San Jose, CA 95134 641 USA 643 Email: snandaku@cisco.com 645 Christer Holmberg 646 Ericsson 647 Hirsalantie 11 648 Jorvas 02420 649 Finland 651 Email: christer.holmberg@ericsson.com