idnits 2.17.1 draft-ietf-simple-im-session-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 23 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '...e a MESSAGE session MUST construct and...' RFC 2119 keyword, line 170: '...that the The UAC MUST include an SDP b...' RFC 2119 keyword, line 189: '... The UAC MUST be prepared to receive...' RFC 2119 keyword, line 213: '... MUST NOT send any request other tha...' RFC 2119 keyword, line 214: '...call leg, and it MUST NOT violate the ...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Under normal conditions, SIP endpoints use the BYE request on the signal channel to end a message session just like they would with any other session. If the session is bi-directional, that is, consists of two unidirectional session call legs, the BYE request tears down both call-legs. And endpoint MUST not attempt to send the bye in the message session itself. -- 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 (July 13, 2001) is 8320 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: '4' is defined on line 409, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-03 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) == Outdated reference: A later version (-01) exists of draft-rosenberg-sip-conferencing-models-00 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Campbell 3 Internet-Draft J. Rosenberg 4 Expires: January 11, 2002 dynamicsoft 5 July 13, 2001 7 SIP Instant Message Sessions 8 draft-ietf-simple-im-session-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 11, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 The current specification for the SIP MESSAGE request method 40 indicates that SIP instant messages according to a model similar to 41 that of a text pager, in that each message stands alone. There is no 42 concept of a chat session or a text conference where there is a 43 stream of messages that are grouped into a session. This memo 44 proposes a method of describing MESSAGE sessions by treating the 45 message session just like any other media session described in an 46 SDP body in an INVITE request. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 53 4. User Agent Client Behavior . . . . . . . . . . . . . . . . . . 5 54 5. User Agent Server Behavior . . . . . . . . . . . . . . . . . . 6 55 6. Nature of MESSAGE sessions . . . . . . . . . . . . . . . . . . 6 56 7. Ending Message Sessions . . . . . . . . . . . . . . . . . . . 7 57 8. Identifying Sessions . . . . . . . . . . . . . . . . . . . . . 7 58 9. Message Sessions over SIP Proxies . . . . . . . . . . . . . . 7 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 The SIP MESSAGE method does not currently support any sense of a 69 session. Instant messages sent using this method are treated like 70 pager messages. Each message stands alone, and is not linked into a 71 conversation. There has been recent interest in the idea of a SIP 72 based instant message session, where the user experience is more 73 akin to a a text conference or a chat room. This document proposes 74 the idea of treating SIP instant message sessions as a media type 75 that can be initiated using the same SIP mechanisms as for any other 76 media type. 78 In this approach, a SIP endpoint that wishes to initiate a text chat 79 session would send an INVITE request with an SDP body that describes 80 the session [2]. The sender and recipient then negotiate MESSAGE 81 sessions using normal SIP conventions. 83 2. Motivation 85 The SIP MESSAGE request method [3] does not create a session. Each 86 MESSAGE request/response exchange fully stands alone, and is not 87 affected by previous exchanges. This is a perfectly good model for 88 many uses of instant messages, such as SMS messages to wireless 89 devices, etc. This document in no way deprecates the stand-alone 90 model of instant messaging, as a session concept is an undue burden 91 for a single message. However, many Instant Message applications 92 support the concept of a message session in the form of a conference 93 or a chat room, in which two (or commonly more) users hold a 94 conversation that is displayed as a coherent whole. 96 The stand-alone model has a number of limitations. It only supports 97 multi-party messaging in very clumsy ways, while using INVITE to 98 establish a session allows reuse of the various multi-party 99 conferencing models supported by SIP[5]. 101 The stand-alone model by necessity causes MESSAGE requests to follow 102 the SIP signal path, which is intended to manage sessions, not 103 transfer content. 105 Forking of MESSAGE requests does not work well either. The sender 106 will not know how many recipients have gotten the message. The 107 sender will not be able to select one of those recipients as the 108 target for future messages. These problems are resolved by 109 establishing a session with INVITE. In that case, the caller does 110 know who has received the session invitation, and can select which 111 recipient(s) to communicate with. 113 Finally, MESSAGE sessions treated as a normal media stream allow us 114 to combine MESSAGE streams with other types of media. For example, 115 one could establish a conference call with a text sub-channel, or 116 send closed captioning along with a video stream. 118 3. Overview of Operation 120 Let us imagine a SIP endpoint Alice, which wishes to initiate a chat 121 session with Bob. Alice constructs an INVITE request with an SDP 122 body, and includes the following line in the SDP:[4] 124 m=message 5060 sip sip:alice@alicepc 126 Bob's UAS receives the INVITE, and responds with a 200 OK containing 127 the following SDP line: 129 m=message 5061 sip sip:bob@bobpda:5061 131 Finally, Alice follows up with an ACK request. 133 At this point, Alice and Bob can each send MESSAGE requests directly 134 to the other. Note that each direction is an independent media 135 stream, and will have a distinct combination of To, From, and 136 Call-ID headers, as well as distinct CSeq spaces. 138 Additionally, the To, From, and Call-ID headers and CSeq spaces are 139 independent from those of the signaling session. 141 The following call flow illustrates the basic message session model, 142 where the signal path goes through a record-routing proxy, but the 143 message session path is end-to-end. 145 ______ _______ _______ 146 | Alice| | Proxy | | Bob | 147 | | | | | | 148 ------ ------- ------- 149 | | | 150 |--------INVITE---------->| | 151 | |---------INVITE--------->| 152 | |<-----F3 200 OK----------| 153 |--------ACK ------------>| | 154 | |---------ACK------------>| 155 |-------------------MESSAGE-(Call leg A)----------->| 156 |<------------------200 OK--------------------------| 157 | | | 158 |<------------------MESSAGE-(Call leg B)------------| 159 |-------------------200 OK------------------------->| 160 | | | 161 }---------BYE------------>| | 162 | |----------BYE----------->| 164 4. User Agent Client Behavior 166 A UAC wishing to initiate a MESSAGE session MUST construct and 167 INVITE request. The headers of the INVITE must be generated 168 according to the normal rules of SIP [1]. The methods for 169 negotiating the MESSAGE streams is the same as for SIP in general, 170 except that the The UAC MUST include an SDP body in the INVITE 171 containing the description of the desired inbound MESSAGE session, 172 i.e. the URL at which it would like to receive MESSAGE requests as 173 part of this session. The SDP format for describing SIP message 174 sessions is described in the SIP Message SDP draft [2] This is 175 different than in general SIP which allows the UAC to defer 176 proposing its media selection until the ACK request. 178 It is tempting to allow the UAC to defer the media specification, 179 so that the SDP is carried in the 200 class response and the ACK 180 request, instead of in the INVITE request and the 200 class 181 response. This would be useful for 3PCC style applications. 182 However, if the UAC omits the media description for the MESSAGE 183 session, there is a high likelyhood that the UAS will not propose 184 a message media type in the 200 response. There is still a 185 possibility for the UAC to accept a non-text media type proposed 186 by the UAS, but it will no longer be possible to accomplish the 187 original goal, i.e. establish a MESSAGE session. 189 The UAC MUST be prepared to receive MESSAGE requests to its proposed 190 URL prior to the completion of the INVITE transaction; that is, 191 before receiving a 200 class response or sending an ACK request. 193 5. User Agent Server Behavior 195 A UAS that receives an INVITE containing an SDP description handles 196 media negotiation according to the normal rules of SIP[1] Since the 197 message media type does not have a concept of codecs, negotiation of 198 message media sections is considerably more simple than for RTP 199 media sections. 201 The UAS must be prepared to receive MESSAGE request to its proposed 202 URL prior to the completion of the INVITE transaction; that is, 203 before receiving an ACK request. 205 6. Nature of MESSAGE sessions 207 A MESSAGE session takes the form of a SIP call-leg, and is 208 identified in the same way as general SIP call legs. A message 209 session is peculiar in the fact that each call-leg is one way only. 210 A two-way chat between two SIP endpoints contains two call legs; one 211 in each direction. Each endpoint may send MESSAGE requests to the 212 URL that was advertised in the opposite end-points SDP. An endpoint 213 MUST NOT send any request other than MESSAGE on a message session 214 call leg, and it MUST NOT violate the directionality of the 215 call-leg; that is to say it SHOULD respond to MESSAGE requests sent 216 to it, but it MUST NOT attempt to send MESSAGE request back along 217 the same call leg. If an endpoint receives a request that violates 218 directionality, it SHOULD respond with a 481, as if the call leg 219 never existed. If an endpoint receives a request with a method other 220 than MESSAGE it SHOULD respond with a 405. 222 When a UAC sends a MESSAGE request on a session, it MUST set the 223 Request-URI to the URL specified in its opposite's SDP, and send the 224 request according to normal SIP rules for resolving a Request-URI. 225 If the supplied URL contains headers, the UAC MUST include those 226 headers in its MESSAGE request.One exception is CSeq; if the URL 227 included a CSeq header, the UAC SHOULD ignore it, and generate its 228 initial CSeq normally. 230 The UAC MUST repeat this process for each MESSAGE requests it sends, 231 following normal SIP rules for sending requests on a call-leg. Note 232 that since MESSAGE requests and their responses will not contain 233 CONTACT headers, each MESSAGE request on a call leg MUST be sent 234 along the same path as the initial request. A MESSAGE request MUST 235 include a pre-loaded route set if the advertised URL containted 236 ROUTE headers. 238 The MESSAGE method is specified to have no session semantics into 239 itself. In particular,a proxy should not insert a Record-Route 240 header into a MESSAGE request[3]. To do would have no meaning. 242 Even though the MESSAGE request may occur in the context of a 243 message session, they may go through a proxy that has no 244 knowledge of the session, and will treat each request as a 245 stand-alone MESSAGE. If that proxy needs to stay in the MESSAGE 246 path for one reason or another (for example, it is a firewall 247 proxy) it cannot use Record-Route to accomplish this. If 248 subsequent MESSAGE requests went to the URL in a Contact header, 249 it would not be possible for the proxy to stay in the path. 251 MESSAGE requests inside a message session MUST NOT overlap. That is, 252 when the UAC sends one MESSAGE request, it may not send another 253 until the first transaction has completed. 255 7. Ending Message Sessions 257 Under normal conditions, SIP endpoints use the BYE request on the 258 signal channel to end a message session just like they would with 259 any other session. If the session is bi-directional, that is, 260 consists of two unidirectional session call legs, the BYE request 261 tears down both call-legs. And endpoint MUST not attempt to send the 262 bye in the message session itself. 264 If a UACs attempt to send a MESSAGE request fails, either do to a 265 negative responsd from the UAS or a timeout waiting for a response, 266 it should behave as it would for any other media stream failure. 268 8. Identifying Sessions 270 A SIP endpoint MUST advertise a URL which allows it to determine 271 which call legt an incoming message is for. It can do that by 272 embedding a Call-ID header in the URL, or by using a special user 273 name unique to the call leg. 275 9. Message Sessions over SIP Proxies 277 In a perfect world, all message sessions would be end-to-end. In 278 this case, end-to-end refers to the scenario where the URL 279 advertised by each endpoint directly maps to the endpoint itself. In 280 reality, there are situations where message sessions may need to 281 cross SIP proxies. For example, an endpoint may wish to conceal its 282 address, or may be behind a firewall where all traffic must go 283 through a particular proxy. 285 In the simplest proxy case, the endpoint merely advertises a URL to 286 a proxy that knows how to route MESSAGE requests to the desired 287 endpoints. For example, a the endpoint might send the following 288 registration: 290 REGISTER sip:biloxi.com SIP/2.0 291 Via: SIP/2.0/UDP bobpda.biloxi.com 292 From: <sip:bob@biloxi.com>;tag=23qk 293 To: sip:bob@biloxi.com 294 Call-ID:739421@bobpda.biloxi.com 295 CSeq: 13 REGISTER 296 Contact: sip:bob@bobpda.biloxi.com; methods=MESSAGE 297 Expires: 600 299 Then the endpoint could send an invite where the SDP contained 300 sip:bob@biloxi.com. In this case, all MESSAGE requests sent on the 301 session would transverse the proxy. 303 Another approach is to place a pre-loaded route header directly to 304 the advertised URL. For example, Alice might include the following 305 m-line in the body of the INVITE she sent to Bob: 307 m=message 5060 sip 308 sip:alice@atlanta.com?Route=sip:alicepc.atlanta.com&Call-ID=34reid2jk@alicepc.atlanta.com 310 Bob then sends each MESSAGE request to the proxy at sip:atlanta.com 311 with a pre-loaded route header instructing the proxy to route the 312 request to sip:alicepc.atlanta.com. 314 And endpoint may also need to route MESSAGE requests through a 315 default outbound proxy, regardless of whether they are in-session or 316 stand-alone. Since each request follows the same path as the initial 317 request this will work without a problem. It is interesting to note 318 that the default outbound proxy will stay in the message session 319 path even if it does not request Record-Routing. 321 10. Security Considerations 323 Message sessions have all of the same security considerations as any 324 other media type used with SIP sessions. A primary issue is the 325 exposure of end-point addresses to the opposite end-point (and 326 anything in between.) This is slightly mitigated with message 327 sessions, as an intervening proxy may be used to hide the end-point 328 address. The deprecation of Contact headers in MESSAGE transactions 329 also mitigates that issue slightly. 331 Another issue is the possibility that a rogue endpoint could 332 establish a message session in the absence of an INVITE transaction 333 by simply guessing the URL to which to send messages. This 334 opportunity is reduced if the endpoints add difficult to guess 335 Call-ID headers into the URLs advertised in their SDP, and only 336 accept MESSAGES with a matching call ID. Still, an attacker could 337 sniff the network and capture the Call-ID if the INVITE transaction 338 is transmitted in the clear. Note that this problem is much worse 339 for audio media streams since they only have 64k ports to guess 340 from, while Call-ID space is effectively infinite. 342 An endpoint may apply any of the general SIP authentication methods 343 to message sessions. 345 11. Open Issues 347 We assert that all requests in a message session must follow the 348 same path as the initial MESSAGE request. But what if we encounter a 349 redirect server? It seems inefficient to require each request to 350 individually get redirected, instead of remembering the contact from 351 the redirect server. 353 The inability for a proxy to Record-Route a MESSAGE request causes 354 some ugliness. Since we are then forced to send all request via the 355 same path as the original MESSAGE, we make it impossible for a proxy 356 to _not_ stay in the message session path. At the same point in 357 time, it would be really ugly to have different semantics for 358 MESSAGE requests depending on whether they were in-session or 359 stand-alone. 361 Another point that came up on the list is we need a way to tell and 362 endpoint to route messages along the signal path. This draft does 363 not address that problem. It might be possible to simply leave the 364 URL out of the m-line, and have endpoints recognize that to mean to 365 use the signal path. I am not confident enough in that approach to 366 propose it in the main body of this draft. 368 Does this draft need to discuss negotiating what mime-types are 369 permitted in the bodies of in-session MESSAGE requests? 371 This approach handles forking of the INVITE transaction just fine. 372 But what if the message session itself crosses a forking proxy? Each 373 subsequent request in the call leg will also fork. Is this a problem? 375 Robert brought up a concern about the performance of message 376 sessions, since we cannot overlap MESSAGE transactions in a 377 call-leg. The fact that each call-leg is one-way helps this a 378 little, but it is still sub-optimal. 380 Do we need to make special considerations for message sessions over 381 TLS? 383 We have effectively introduced the idea of SIP call leg nesting. 384 Should this be generalized? 386 12. Acknowledgments 388 This document is a compilation of the thoughts of many people on the 389 SIMPLE mail list. In particular, the authors thank the following for 390 their contributions: Christian Heitema, Sean Olson, Adam Roach, 391 Robert Sparks, Henning Schulzrinne, and James Undery. 393 References 395 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 396 "SIP: Session Initiation Protocol", 397 draft-ietf-sip-rfc2543bis-03.txt (work in progress), May 2001. 399 [2] Campbell, B. and J. Rosenberg, "SDP Extensions for SIP Instant 400 Message Sessions", internet-draft 401 draft-ietf-simple-im-sdp-00.txt, July 2001. 403 [3] Rosenberg, J. , Willis, D. , Rosenberg, J. , Sparks, R. , 404 Campbell, B. , Schulzrinne, H. , Lennox, J. , Huitema, C. , 405 Aboba, B. , Gurle, D. and D. Oran, "SIP Extensions for 406 Instant Messaging", draft-ietf-simple-im-01.txt (work in 407 progress), July 2001. 409 [4] Handley, M. and V Jacobson, "SDP: Session Description 410 Protocol", RFC 2327, April 1998. 412 [5] Rosenberg, J. and H. Schulzrinne, "Models for Multi Party 413 Conferencing in SIP", 414 draft-rosenberg-sip-conferencing-models-00.txt (work in 415 progress), November 2000. 417 Authors' Addresses 419 Ben Campbell 420 dynamicsoft 421 5100 Tennyson Parkway 422 Suite 1200 423 Plano, TX 75024 425 email: bcampbell@dynamicsoft.com 426 Jonathan Rosenberg 427 dynamicsoft 428 72 Eagle Rock Avenue 429 First Floor 430 East Hanover, NJ 07936 432 email: jdrosen@dynamicsoft.com 434 Full Copyright Statement 436 Copyright (C) The Internet Society (2001). All Rights Reserved. 438 This document and translations of it may be copied and furnished to 439 others, and derivative works that comment on or otherwise explain it 440 or assist in its implementation may be prepared, copied, published 441 and distributed, in whole or in part, without restriction of any 442 kind, provided that the above copyright notice and this paragraph 443 are included on all such copies and derivative works. However, this 444 document itself may not be modified in any way, such as by removing 445 the copyright notice or references to the Internet Society or other 446 Internet organizations, except as needed for the purpose of 447 developing Internet standards in which case the procedures for 448 copyrights defined in the Internet Standards process must be 449 followed, or as required to translate it into languages other than 450 English. 452 The limited permissions granted above are perpetual and will not be 453 revoked by the Internet Society or its successors or assigns. 455 This document and the information contained herein is provided on an 456 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 457 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 458 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 459 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 460 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 Acknowledgement 464 Funding for the RFC editor function is currently provided by the 465 Internet Society.