idnits 2.17.1 draft-sinnreich-sip-tools-07.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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) ** 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 657: '...equirements that MUST be considered. T...' 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 (June 29, 2009) is 5387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '12' on line 763 looks like a reference -- Missing reference section? '13' on line 766 looks like a reference -- Missing reference section? '30' on line 821 looks like a reference -- Missing reference section? '31' on line 824 looks like a reference -- Missing reference section? '14' on line 769 looks like a reference -- Missing reference section? '15' on line 773 looks like a reference -- Missing reference section? '16' on line 776 looks like a reference -- Missing reference section? '17' on line 779 looks like a reference -- Missing reference section? '29' on line 438 looks like a reference -- Missing reference section? '1' on line 727 looks like a reference -- Missing reference section? '2' on line 730 looks like a reference -- Missing reference section? '3' on line 733 looks like a reference -- Missing reference section? '4' on line 736 looks like a reference -- Missing reference section? '5' on line 739 looks like a reference -- Missing reference section? '6' on line 742 looks like a reference -- Missing reference section? '7' on line 745 looks like a reference -- Missing reference section? '8' on line 748 looks like a reference -- Missing reference section? '9' on line 751 looks like a reference -- Missing reference section? '10' on line 754 looks like a reference -- Missing reference section? '11' on line 758 looks like a reference -- Missing reference section? '18' on line 782 looks like a reference -- Missing reference section? '19' on line 786 looks like a reference -- Missing reference section? '20' on line 790 looks like a reference -- Missing reference section? '22' on line 793 looks like a reference -- Missing reference section? '23' on line 796 looks like a reference -- Missing reference section? '27' on line 811 looks like a reference -- Missing reference section? '26' on line 807 looks like a reference -- Missing reference section? '28' on line 815 looks like a reference -- Missing reference section? '24' on line 800 looks like a reference -- Missing reference section? '25' on line 804 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group H. Sinnreich/Adobe, editor 2 Internet Draft A. Johnston/Avaya 3 E. Shim/Avaya 4 K. Singh/Columbia U. Alumni 5 Intended status: Informational 6 June 29, 2009 7 Expires: December 2009 9 Simple SIP Usage Scenario for Applications in the Endpoints 10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Copyright (c) 2009 IETF Trust and the persons identified as the 18 document authors. All rights reserved. 20 This document is subject to BCP 78 and the IETF Trust's Legal 21 Provisions Relating to IETF Documents in effect on the date of 22 publication of this document (http://trustee.ietf.org/license-info). 23 Please review these documents carefully, as they describe your rights 24 and restrictions with respect to this document. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire in October 2009. 43 This document is subject to the rights, licenses and restrictions 44 contained in BCP 78, and except as set forth therein, the authors 45 retain all their rights." 47 "This document and the information contained herein are provided on 48 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 49 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 50 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 51 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 52 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 53 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 54 PARTICULAR PURPOSE." 56 Abstract 58 For Internet-centric usage, the number of SIP required standards for 59 presence; IM and audio/video communications can be drastically 60 smaller than what has been published, by using only the rendezvous 61 and session initiation capabilities of SIP. The simplification is 62 based on avoiding emulating telephony and its model of the 63 intelligent network. 'Simple SIP' by contrast relies on powerful 64 computing endpoints. Simple SIP desktop applications can be combined 65 with rich Internet applications (RIA). Significant telephony features 66 may also be implemented in the endpoints. 68 This approach for SIP reduces the number of SIP standards to comply 69 with, currently from roughly 100 and still growing, to about 11. 71 References for NAT traversal and for security are also provided. 73 Table of Contents 75 1. Introduction................................................3 76 2. The Endpoint in the SIP and Web Architectures...............5 77 The Telephony Gateway as a SIP Endpoint........................7 78 3. Applicability for 'simple SIP' in the Endpoints.............7 79 What 'simple SIP' can accomplish...............................7 80 Baseline for 'simple SIP'......................................8 81 What 'simple SIP' may or may not accomplish....................8 82 What is out of scope for 'simple SIP'..........................8 83 Borderline cases...............................................9 84 4. Mandatory SIP References for Internet-Centric Usage........10 85 RFC 3261: "SIP: Session Initiation Protocol"..................10 86 RFC 4566: "SDP: Session Description Protocol".................10 87 RFC 3264: "An Offer/Answer Model with SDP"....................11 88 RFC 3840: "Indicating User Agent Capability in SIP"...........11 89 RFC 3263: "SIP: Locating SIP Servers".........................11 90 RFC 3265: "SIP-Specific Event Notification"...................11 91 RFC 3856: "A Presence Event Package for SIP"..................12 92 RFC 3863: "Presence Information Data Format (PIDF)"...........12 93 RFC 3428: "SIP Extension for Instant Messaging"...............12 94 RFC 4474: "Enhancements for Authenticated Identity Management in 95 SIP"..........................................................12 96 RFC 3581: "An Extension to SIP for Symmetric Response Routing"12 97 Updates to SIP Related Protocols..............................13 98 5. SIP Applications in the Endpoints..........................13 99 6. NAT Traversal..............................................14 100 7. Security Considerations....................................15 101 8. IANA Considerations........................................16 102 9. Acknowledgements...........................................16 103 10. References.................................................16 104 10.1 Mandatory References.....................................17 105 10.2 Informative References...................................17 106 Acknowledgment...................................................19 108 1. Introduction 110 The Session Initiation Protocol (SIP) has become the global standard 111 for real time multimedia communications over the Internet and in 112 private IP networks, due to its adoption by service providers and in 113 enterprise networks alike. The cost of this success has been a 114 continuing increase in complexity to accommodate the various 115 requirements for such networks. At the same time, the World Wide Web 116 has become the platform for a boundless variety of Rich Internet 117 Applications (RIA), both in the browser and on the desktop. For SIP 118 to be useful for RIA, legacy voice service provider requirements that 119 add unnecessary complexity may be avoided by delegating the 120 interworking to telephony gateway endpoints. This usage scenario for 121 SIP requires following the end-to-end principle of the Internet 122 architecture at the application level, or in other words, placing SIP 123 applications in the endpoints. 125 There are several reasons from the Web services perspective to place 126 most or all SIP applications in the endpoints and just use the 127 client-server (CS) or peer-to-peer (P2P) rendezvous function for SIP: 129 1. Value proposition: SIP applications in the endpoints can be easily 130 mixed with RIA and thus enable service providers to offer new 131 services in a scalable and flexible manner as well as 132 significantly enhance the value of SIP applications. Rich Internet 133 applications support unrestricted user choice as an alternative to 134 and beyond what is traditionally prepackaged as network based 135 communication service plans. 137 2. Eliminating the problems associated with distributed SIP 138 applications in various feature servers across the network allows 139 us to greatly simplify SIP. There is also the Internet end-to-end 140 principle that argues that network intermediaries cannot 141 completely understand the applications and their state in the 142 endpoints. 144 We will refer in the following by 'simple SIP' to the SIP functions 145 necessary to only support the rendezvous and session setup functions 146 of SIP, support voice, video, basic presence and instant messaging 147 and also support security. Simple SIP is focused on providing a basic 148 multimedia real time communications "call". This includes presence, 149 instant messaging, voice and video for point to point and various 150 conference applications. One or a very small number of additional 151 servers may also be provided, for example a voice mail server as an 152 auxiliary to making a simple one-to-one call to voice mail if the 153 callee does not answer, or to check voice mail. 155 Once the applications in the endpoints have established basic 156 communications, it is up to them to support available features 157 selected by users. This paper is targeted to such scenarios. In 158 telephony, most of the value to users and service providers alike is 159 added by signaling. By contrast, on the Web, RIA adds most of the 160 value. The integrated use of SIP and RIA in the endpoints can combine 161 the best of both. 163 This approach limits the number of SIP standards to roughly 11 that 164 are listed here as the core for simple SIP. At the time of this 165 writing, the Real-Time Applications and Infrastructure (RAI) area of 166 the IETF is focused on a dedicated working group for the core SIP 167 protocol, separate from various SIP applications. We anticipate this 168 emerging work will also be the core of what is termed here as 'simple 169 SIP' and will actually further reduce the number of references that 170 reflect the present core SIP standards. 172 This memo aims to shield Web application developers from the need to 173 know or understand more than the core SIP protocol. The total number 174 of references has been kept to a minimum and includes other related 175 topics, such as examples for providing telephony services in the 176 endpoints, NAT traversal and security. The referenced papers are 177 however entry points to these knowledge resources. Readers interested 178 in a more detailed list of SIP topics, especially telephony, can 179 follow up the short list here with the extensive list in "A 180 Hitchhikers' Guide to SIP", RFC 5411 [12]. The guide has over 140 181 references for understanding most, but not all of the published 182 features of SIP in the IETF and elsewhere. There is also a Web site 183 that automatically tracks the number of SIP related RFCs [13]. Other 184 standards and commercial organizations have greatly enlarged the 185 published features of SIP as well. We could not actually provide a 186 complete count on everything that has been published as some form of 187 SIP standard document. 189 NAT traversal is also a basic requirement for simple SIP. Given 190 however the potential option of using the Host Identity Protocol 191 (HIP) in SIP enabled endpoints as shown in section 4, 'simple SIP' 192 may not require any other standards than those mentioned here. The 193 alternative to HIP is to use SIP specific protocols for NAT traversal 194 such as STUN, TURN and ICE discussed in section 4. 196 "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 197 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 198 this document are to be interpreted as described in RFC 2119." 200 2. The Endpoint in the SIP and Web Architectures 202 SIP has been defined in RFC 3261 for rendezvous and session 203 initiation. The usual example is the trapezoid model for 204 communications between two endpoints placed in two different SIP 205 service provider domains. SIP is also flexible, since SIP 206 applications beyond the rendezvous function can reside either in the 207 SIP networks in additional feature servers and media servers, or in 208 the endpoints. SIP endpoints are our focus in this memo. 210 Since SIP has been invented, with much initial similarity between SIP 211 and HTTP, the Web has evolved from a global access mechanism to 212 static documents, to a universal platform with rich interaction 213 between the user and the client. In most cases the client is the 214 browser, though recently dedicated Web desktop clients have emerged 215 as well. 217 The Web provides access to applications as well as to documents. It 218 is beyond the scope to describe here the application and network 219 architectures of the Web. We will note however some of the new 220 application and communication forms that have emerged on the Web as a 221 result of a Darwinian evolution [30], rather than being defined in 222 standards organizations. They are referred to as Rich Internet 223 Applications. 225 Examples of RIA include social networks, blogs, wikis, web based 226 office and collaboration tools, task related apps for to-do lists, 227 tracking time, combining geographic information with various 228 applications such as tracking exercise paths and recording the 229 metrics, tracking airline flights, combining live video from events 230 with results and comments, etc. 232 More information can be found at [31] and in the vast collection of 233 books about RIA. 235 RIA have positioned the browser and associated Web desktop 236 applications, as the dominant platform for a large variety of 237 applications. They are universal application platforms, independent 238 of network location, operating system, processor or display size. 240 Behind the better-known Web applications are a wealth of new 241 technologies that can enhance SIP based communications, for example 242 the aggregation of data at runtime from several resources on the 243 Internet. A variety of RIA components, such as found on interactive 244 Web pages can significantly improve the user experience of SIP based 245 communications. This is in contrast to the fixed interfaces found in 246 most SIP User Agents such as phones and desktop clients. 248 The Web network and application architecture is very different from 249 SIP service provider networks at present, but the one point where 250 they both meet is the end user device of any shape, fixed or mobile. 252 The desire by SIP service providers to support new services in a 253 scalable and flexible manner is incidentally easier to implement by 254 the loose service coupling on the Web: Characterizing a service, or 255 actually a mix of several service components (such as in a mash-up) 256 by a URI. This is in contrast to network services registration by a 257 central registrar. The Web architecture is also better suited for 258 users to select and configure their applications and interaction mode 259 with the client. The boundless variety of configurations of services 260 and client settings on the Web is in contrast with the prepackaged 261 services and fixed user agent configurations in present SIP services. 263 Last but not least, program execution locally on the client is faster 264 if the interaction with servers across the network is minimized. 266 The potential of integrating SIP based multimedia communications 267 with access to RIA on the Web is the motivation behind this memo. To 268 mention a few scenarios: Adding SIP and RTP based real-time 269 communications to RIA, integrating from a user perspective the SIP 270 location service (not to be confused with geographic location 271 services) with other desktop and network based geographic location 272 services, using social networks as part of the contact list, etc. 274 The Telephony Gateway as a SIP Endpoint 276 Integrating SIP communications into RIA precludes in our opinion 277 carrying over to the Web legacy telephony features in order to 278 accomplish interoperability with the installed base of telephone 279 networks of various kinds. Interoperability between the Internet and 280 telephone networks is best left to gateways that look to the Web as 281 special endpoints serving large numbers of users. Plain one-to-one 282 phone calls are already supported by Internet-to-telephony gateways. 283 If added PSTN or ISDN telephony features must be exposed to Web 284 users, visual Web display and interaction with the user is preferable 285 to carrying the extremely complex SIP equivalents over into the 286 Internet. On the Internet side of telephony gateways, simple SIP is 287 all that needs to be deployed in our opinion. Additional telephony 288 features can be just another RIA hosted in the gateway. The market is 289 the best indicator to show if such an effort is worthwhile to be 290 productized. 292 Overloading simple SIP with telephony features is a non-objective as 293 detailed in section 3. 295 3. Applicability for 'simple SIP' in the Endpoints 297 This section aims to clarify the scope of applicability by 298 considering what can be done better in the endpoints, what simple SIP 299 for user agents can and cannot accomplish and what is out of scope. 300 We will use emergency calls as an example to illustrate these points 301 on applicability. Emergency calls are also a good example to consider 302 if and when SIP plus RIA applications could be used as an emergency 303 telephony enhancement or even replacement. 305 What 'simple SIP' can accomplish 307 The main driver for SIP applications on the desktop or in the browser 308 is to support the integration of SIP and RTP based real time 309 communications with RIA. This assumes powerful endpoints, such as 310 PC/laptop, smart mobile phones or various dedicated devices. 312 Example of better functionality: Emergency calls, not limited to a 313 Public Safety Access Point (PSAP), but also extended to a medical 314 service taking care of patients or elderly people. 316 In this case, besides alerting the right medical provider of the 317 emergency, vital body sign data and video can also be transmitted. In 318 the opposite direction, the caller may get visual and audio 319 information and instructions for instant self-help. In this scenario, 320 there is no need to invoke a PSAP service. A dedicated device for 321 such scenarios may actually have an emergency medical call button, 322 though for telephone calls to a PSAP this is not recommended [14]. 323 Powerful endpoints may also have various means to determine the 324 geographic location and transmit it to the emergency care provider. 325 In this and other examples, SIP voice may be a component of several 326 other communications means, but not always the central one: Some 327 emergency communications and data transfer may actually be performed 328 without voice, such instances as when the "caller" cannot speak for 329 some reason. 331 Baseline for 'simple SIP' 333 The focus of the memo is to define the baseline for 'simple SIP': 334 The establishment of a one-to-one real-time multimedia communication 335 session for presence, IM, voice and video. Adequate security must 336 also be provided: Authentication, encryption for the media and for 337 parts of the signaling in a manner consistent with the routing of SIP 338 messages. 340 What 'simple SIP' may or may not accomplish 342 There are border cases where simple SIP may or may not accomplish 343 some necessary legacy function. Example: An emergency call to a PSAP 344 over the Internet may be supported using the SOS URN [15] and the 345 LoST [16] protocol to determine where to route the call. If however 346 emergency calls must be routed over the PSTN to a country specific 347 telephone number; the assistance of a SIP proxy and also a SIP-PSTN 348 gateway is required to recognize and route the emergency call. 349 Depending on the local jurisdiction, emergency calls from a SIP UA 350 may require other features that are beyond the scope of this memo. 352 What is out of scope for 'simple SIP' 354 The simple usage of SIP is applicable when avoiding the traditional 355 voice provider approaches for charging (or monetizing) that aim to 356 provide, manage and charge for what is referred to as services (not 357 applications), some examples of which are listed here. This means to 358 avoid placing any functions in the network other than the rendezvous 359 function of SIP. 361 o Avoiding the support of legacy telephony functions, such as 362 emulating public telephone switch services and voice-only 363 private branch exchanges. 365 o Avoiding SIP network architectures designed to support 366 telephony type network models. Examples include long chains of 367 SIP proxies and feature servers, more than the two SIP servers 368 shown in RFC 3261, that may be encountered inside and between 369 closed VoIP networks and in transit VoIP networks in between. 370 Long chains of intermediaries of any type are not only adding 371 complexity, they pose a security risk that increases with the 372 number of SIP network elements. Complex server based networks 373 also make it more difficult to introduce new services. A 374 special problem in SIP server chains is forking that leads to 375 the well-known problems of concurrency in computing; the so- 376 called race conditions in telephony. This is amplified by 377 redesigning the whole network every time there is new SIP 378 routing requirement. 380 o Avoiding the support for legacy telephony models such as 381 identifying end user devices for the purpose of differentiated 382 charging by type of service or charging for roaming between 383 networks. 385 o Avoiding policies and the associated policy servers and network 386 elements for Quality of Service (QoS) to enforce service rate 387 specific policies for real-time communications. 389 o Avoiding design considerations for SIP for compatibility with 390 legacy telephony networks, traditional telephony services and 391 the various telephone numbering plans. This pushes the 392 responsibility of mapping the URI to telephone numbers to edge 393 networks where the IP-PSTN gateway functions are performed. The 394 handling of telephony specific functions such as early media 395 are also pushed to edge gateway networks. Other design 396 considerations for interworking with the PSTN and to 'look like 397 the PSTN' are also avoided. 399 This list is not exhaustive, but conveys the concept on what to avoid 400 when using SIP as a simpler protocol to understand and to implement. 402 Borderline cases 404 There are also some interesting borderline cases for what to avoid, 405 such as the Reliability of Provisional Responses (PRACK) specified in 406 RFC 3262. PRACK is targeted for multi-hop SIP server networks and 407 PSTN interworking, especially to assure reliable early media. PRACK 408 can be delegated, albeit with some limitations to the SIP-PSTN 409 gateway. PRACK does little to improve the user experience and has no 410 relevance on true broadband networks with minimal SIP hop counts. 411 Using PRACK may therefore be a decision best left to designers. 413 Another interesting example of a borderline case are the issues with 414 SIP's Non-Invite transactions as discussed in RFC 4320 [17]. Long 415 chains of SIP intermediaries complicate the handling of provisional 416 responses and may create several problems such as storms of late 417 responses from forked SIP forwarding paths. We mentioned that long 418 chains of SIP intermediaries are out of scope for simple SIP, but 419 since designers may encounter various scenarios, even those they 420 don't like, the decision to conform the UA to RFC 4320 is best left 421 to them. 423 The list of borderline cases is also not exhaustive and the above are 424 only examples. So where is the borderline? We believe that SIP usage 425 on the Internet, without any intermediaries designed to support 426 closed VoIP networks eliminates the borderline cases. Enterprise SIP 427 networks are also most useful when designed to work with the Internet 428 model in mind; by giving enterprise users the benefit of SIP enhanced 429 Web applications for productivity. Handling of SIP in enterprise 430 firewalls is out of the scope in this memo. 432 4. Mandatory SIP References for Internet-Centric Usage 434 Here is the minimal set of mandatory references to support the 435 Internet-centric approach to SIP outlined above. The minimal set of 436 references defines 'simple SIP'. 438 The proposed change process [29] for SIP in the IETF RAI area will 439 define the updated SIP core specification and thus reduce even more 440 the required SIP standards for what is referred here to as 'simple 441 SIP'. 443 RFC 3261: "SIP: Session Initiation Protocol" 445 RFC 3261 [1] is the core specification for SIP. The trapezoid model 446 for SIP RFC 3261 is only an example and a use case applicable to two 447 service providers featuring an outgoing SIP proxy and an incoming SIP 448 proxy in each domain respectively. SIP however can also work in peer- 449 to-peer (P2P) communications without SIP servers. 451 RFC 4566: "SDP: Session Description Protocol" 453 SDP [2] is the standard format for the representation of media 454 parameters, transport addresses and other session data irrespective 455 of the protocol used to transport the SDP data. SIP is one of the 456 protocols used to transport SDP data, to enable the setting up of 457 multimedia communication sessions. Other Internet application 458 protocols use SDP as well. 460 RFC 3264: "An Offer/Answer Model with SDP" 462 Though SDP has the capability to describe SIP sessions, how to arrive 463 at a common description by two SIP endpoints requires a negotiation 464 procedure to agree on common media codecs along with IP addresses and 465 ports where the media can be received. This negotiation procedure is 466 specified in RFC 3264 [3]. As will be seen in the following on NAT 467 traversal, this negotiation is usually considerably complicated due 468 to the existence of NAT between the SIP endpoints. 470 RFC 3840: "Indicating User Agent Capability in SIP" 472 A SIP UA can convey its capability in the Contact header field 473 indicating if it can support presence, IM, audio, video, if the 474 device is fixed or mobile and other such as the endpoint being an 475 automaton; voice mail for example. Which SIP methods are supported 476 may also be indicated as specified in RFC 3840 [4]. SIP registrars 477 (SIP servers or the P2P SIP overlay) can be informed of endpoint 478 capabilities. Missing capabilities can be displayed for the user by 479 such as grayed out or missing icons. 481 RFC 3263: "SIP: Locating SIP Servers" 483 RFC 3263 [5] adds key clarifications to the base SIP specification in 484 RFC 3261 by specifying how a SIP user agent (UA) or SIP server can 485 determine with DNS queries not only the IP addresses of the target 486 SIP servers, but also which SIP servers can support UDP or TCP 487 transport, as required. TCP may be required to support secure SIP 488 (SIPS) using TLS transport or when SIP messages are too large to fit 489 into UDP packets without fragmentation. Successive DNS queries yield 490 finer grain location by providing NAPTR, SRV and A type records. Note 491 that finding a SIP server requires several successive DNS queries to 492 access these records. 494 Locating SIP servers is also required for P2P SIP when a peer node 495 wishes to communicate with a SIP UA outside its own P2P SIP overlay 496 network. 498 RFC 3265: "SIP-Specific Event Notification" 500 RFC 3265 [6] provides an extensible framework by which SIP nodes can 501 request notification from remote nodes indicating that certain events 502 have occurred. The most prominent event notifications are those used 503 for presence, though SIP events are used for many other SIP services, 504 some of which can be useful for simple SIP. 506 RFC 3856: "A Presence Event Package for SIP" 508 RFC 3856 [7] defines the usage of SIP as a presence protocol and 509 makes use of the SUBSCRIBE and NOTIFY methods for presence events. 510 SIP location services already contain presence information in the 511 form of registrations, and as such can be reused to establish 512 connectivity for subscriptions and notifications. This can enable 513 either endpoints or servers to support rich applications based on 514 presence. 516 RFC 3863: "Presence Information Data Format (PIDF)" 518 RFC 3863 [8] defines the Presence Information Data Format (PIDF) and 519 the media type "application/pidf+xml" to represent the XML MIME 520 entity for PIDF. PIDF is used by SIP to carry presence information. 522 RFC 3428: "SIP Extension for Instant Messaging" 524 The SIP extension for IM in RFC 3428 [9] consists in the MESSAGE 525 method defined here only for the pager model of IM based on the 526 assumption that an IM conversation state exists in the client 527 interface in the endpoints or in the mind of the users. 529 RFC 4474: "Enhancements for Authenticated Identity Management in SIP" 531 RFC 4474 [10] defines (1) an identity header and (2) an identity info 532 header for SIP requests that carry respectively the signature of the 533 issuer over parts of the SIP request and the signed identity 534 information. The signature includes the FROM header and the identity 535 of the sender. The associated identity info header identifies the 536 sender of the SIP request, such as INVITE. The issuer of the 537 signature can present their certificate as well. It is assumed the 538 issuer may be the domain owner. Strong authentication is thus 539 provided for SIP requests. Authentication for SIP responses is not 540 defined in this document. 542 RFC 3581: "An Extension to SIP for Symmetric Response Routing" 544 RFC 3581 [11] specifies an extension to SIP called "rport" so that 545 responses are sent back to the source IP address and port from which 546 the request originated. This correction to RFC 3261 is helpful for 547 NAT traversal, debugging and support of multi-homed hosts. 549 Updates to SIP Related Protocols 551 Several of the above are being updated to benefit from the experience 552 of large deployments and frequent interoperability testing. We 553 recommend readers to constantly check for revisions. One update 554 example is 556 "Correct Transaction Handling for 200 Responses to the SIP INVITE 557 Requests" [18]. This is an update to RFC 3261. The added security 558 risk for misbehaving SIP UAs is handled in the forwarding SIP proxy. 560 5. SIP Applications in the Endpoints 562 Although the present adoption of SIP is mainly due to telephony 563 applications, its roots are in the Web and it has initial similarity 564 to HTTP. As a result, SIP may play other roles in adequately powerful 565 endpoints (their number keeps increasing with Moore's law). SIP based 566 multimedia communications may be linked with various other 567 applications on the Web. Either some non-SIP application or the 568 communication feature may be perceived as the primary usage. An 569 example is mixing SIP based real-time communications with some Web 570 content of high interest to the user. 572 Examples: 574 1. In a conversation between a consumer and the contact center, a Web 575 conference can be invoked to present to the user buying options or 576 help information. This information can make use of mashups to 577 combine real-time data from various sources on the Web. 578 2. In a social network, multimedia conversations combined with Web 579 mashups can be invoked thus strengthening the bond between its 580 members. 581 3. Conversations can be invoked while watching some events on the Web 582 in real time. The main beneficiary in this case may be however the 583 Web site, since the conversation can prolong the time for users 584 watching that Web site. 586 This shows the value of combining RIA with SIP based communications. 588 It is a matter of judgment by the end user if the Web content or the 589 associated communication capability is more important or if the mix 590 of both is most attractive. 592 Example: A Web based enterprise directory where employees can find a 593 wealth of data. Adding SIP multimedia communications to the 594 enterprise directory to call someone if online and not too busy, 595 enhances its usefulness, but is not critical to the directory. 597 SIP applications in the endpoints can however accomplish most 598 telephony functions as well. This has been amply documented in SIP 599 related work in the IETF, such as: 601 o "A Call Control and Multi-party usage framework for SIP" [19] 602 presents a large assortment of telephony applications where the 603 call control resides in the participating endpoints that use 604 the peer-to-peer feature invocation model. The peer-to-peer 605 design and its principles are based on multiparty call control. 607 o "SIP Service Examples" [20] contain a collection of SIP call 608 flows for traditional telephony, many of which require no 609 server support for the respective features. The SIP service 610 examples for telephony are extremely useful, since they 611 illustrate in detail the concepts and applications supported by 612 the core simple SIP references. 614 In conclusion, SIP applications in the endpoints can support both a 615 mix of real-time communications with new rich Internet applications 616 and traditional telephony features as well. 618 6. NAT Traversal 620 SIP devices behind one or more NAT are at present the rule rather 621 than the exception. 623 "Best Current Practices for NAT Traversal for SIP" [22] 624 comprehensively summarizes the use of STUN, TURN and ICE. This 625 document provides a definitive set of 'Best Common Practices' to 626 demonstrate the traversal of SIP and its associated RTP media packets 627 through NAT devices. 629 The use of ICE has been developed mainly for SIP. Other proposals 630 such as NICE, generic for non-SIP, and "D-ICE" for RTSP streaming 631 media have also been proposed. Internet games have different NAT 632 traversal techniques of their own. This list is not exhaustive and 633 such approaches are based on different NAT traversal protocols for 634 each application protocol separately. 636 A general, non-application-protocol specific approach for NAT 637 traversal is therefore highly desirable. 639 One approach for NAT traversal that is generic and applicable for all 640 application protocols is to deploy the Host Identity Protocol (HIP) 641 and solve NAT traversal only once, at the HIP level. HIP has many 642 other useful features such as the support for the IPv6 transition in 643 endpoints, mobility and multihoming that are beyond the scope of this 644 paper. "Basic HIP Extensions for Traversal of Network Address 645 Translators and Firewalls" [23] provides an extensive coverage of the 646 use of HIP for NAT traversal. 648 Using HIP enabled endpoints can provide the functions required for 649 NAT traversal [23] for all applications for both IPv4 and IPv6. HIP 650 can thus simplify the SIP UA since it takes away the burden of NAT 651 traversal from the SIP UA and moves it to the HIP protocol module in 652 the endpoint. 654 7. Security Considerations 656 All protocols discussed in this paper have their own specific 657 security requirements that MUST be considered. The special security 658 considerations for SIP signaling security and RTP media security are 659 discussed here. 661 SIP security has two main parts: Transport security and identity. 663 o Transport security for SIP is specified in RFC 3261. Secure SIP 664 has the notation SIPS in the request URI and uses TLS over TCP. 665 Note that SIP over UDP cannot be secured in this way. Transport 666 security works only hop by hop. Specifying SIPS requires the 667 user to trust all intermediate servers and no end-to-end media 668 encryption is assumed. There is no insurance for misbehaving 669 intermediaries in the path. SIPS is therefore really adequate 670 only in single hop scenarios. 672 o RFC 4474: "Enhancements for Authenticated Identity Management 673 in SIP" mentioned previously specifies the use of certificates 674 for secure identification of the parties involved in SIP 675 signaling requests. 677 o The Datagram Transport Layer Security specified in RFC 4347 [27] 678 has wide applicability for other applications that require UDP 679 transport. DTLS has been designed to have maximum commonality 680 with TLS yet does not require TCP transport and works over UDP. 681 The DTLS-SRTP Framework [26] can support encrypted 682 communications between endpoints using self-signed 683 certificates, whose fingerprints are exchanged over an integrity 684 protected SIP signaling channel. The SRTP master secret is 685 derived using the DTLS exchange as described in [27]. 687 o ZRTP [28] provides key agreement for SRTP for multimedia 688 communication with voice without depending on SIP signaling, 689 though it can utilize an integrity protected SIP signaling path 690 for authentication. ZRTP does not require the use of 691 certificates or any Public Key Infrastructure (PKI). 692 ZRTP provides best effort SRTP encryption without any additional 693 SIP extensions. 695 8. IANA Considerations 697 There are no IANA considerations associated with this memo. 699 9. Acknowledgements 701 The authors would like to thank Cullen Jennings, Ralph Droms and 702 Adrian Farrel for helpful comments in the most recent stage of this 703 memo. 705 Special thanks are due to Paul Kyzivat for challenging the authors to 706 clarify the role of telephony network gateways and also to Keith 707 Drage to discuss the use of emergency calls using simple SIP. 709 Robert Sparks has pointed to some missing references, which we have 710 added. 712 The authors would also like to thank Jiri Kuthan, Adrian Georgescu 713 and others for the detailed discussion on the SIPPING WG list. As a 714 result, we have added the clarifications of what simple SIP can do, 715 what it does not aim to do and some scenarios in between. We would 716 also like to thank Wilhelm Wimmreuter for the detailed review of the 717 initial draft and to Arjun Roychaudhury for the comments regarding 718 the need to clarify the difference between network based services and 719 endpoint applications. 721 This document was prepared using 2-Word-v2.0.template.dot. 723 10. References 725 10.1 Mandatory References 727 [1] RFC 3261: "SIP: Session Initiation Protocol." by J. Rosenberg et 728 al. IETF, June 2002. 730 [2] RFC 4566: "SDP: Session Description Protocol" by M. Handley et 731 al. IETF, July 2006. 733 [3] RFC 3264: "An Offer/Answer Model with the Session Description 734 Protocol (SDP)" by J. Rosenberg et al. IETF, June 2002. 736 [4] RFC 3840: "Indicating User Agent Capabilities in SIP" by J. 737 Rosenberg et al. IETF, August 2004. 739 [5] RFC 3263: "SIP: Locating SIP Servers" by J. Rosenberg and H. 740 Schulzrinne. IETF, June 2002. 742 [6] RFC 3265: "SIP-Specific Event Notification" by A. Roach. IETF, 743 June 2002. 745 [7] RFC 3856: "A Presence Event Package for the Session Initiation 746 Protocol" by J. Rosenberg. IETF, August 2004. 748 [8] RFC 3863: "Presence Information Data Format (PIDF)" by J. Sugano 749 et al. IETF, August 2004. 751 [9] RFC 3428: "SIP Extension for Instant Messaging" by B.Campbell et 752 al. IETF, December 2002. 754 [10] RFC 4474: "Enhancement for Authenticated Identity Management in 755 the Session Initiation Protocol (SIP)" by J. Peterson et al. IETF, 756 August 2006. 758 [11] RFC 3581: "An Extension to SIP for Symmetric Response Routing" 759 by J. Rosenberg and H. Schulzrinne. IETF, August 2003. 761 10.2 Informative References 763 [12] RFC 54: "A Hitchhiker's Guide to the Session Initiation 764 Protocol(SIP)" by J. Rosenberg, IETF November 2008. 766 [13] "VoIP RFC Watch by Nils Ohlmeier". Web site counting SIP related 767 standards at http://rfc3261.net/" 769 [14] B. Rosen and J. Polk: "Best Current Practice for Communications 770 Services in support of Emergency Calling". Internet-Draft of the 771 Ecrit WG, IETF, June 2009. Work in progress. 773 [15] RFC 5031: "A Uniform Resource Name (URN) f or Emergency and 774 Other Well-Known Services" by H. Schulzrinne. IETF, January 2008. 776 [16] RFC 5222: "LoST: A Location-to-Service Translation Protocol" by 777 T. Hardie al. IETF, August 2008. 779 [17] RFC 4320: "Actions Addressing Identified Issues with SIP Non- 780 Invite Transactions" by R. Sparks. IETF, January 2006. 782 [18] "Correct Transaction Handling for 200 Responses to the SIP 783 INVITE Requests" by R. Sparks, Internet-Draft, work in progress, 784 IETF, March 2009. 786 [19] "A Call Control and Multi-party usage framework for the Session 787 Initiation Protocol (SIP)" by R. Mahy et al. Internet-Draft. IETF 788 Macrh 2009, work in progress. 790 [20] RFC 5359: "Session Initiation Protocol Service Examples" by A. 791 Johnston et al. IETF, November 2008. 793 [22] "Best Current Practices for NAT Traversal for SIP" by C. Boulton 794 et al., IETF, September 2008. Internet-Draft. 796 [23] "Basic HIP Extensions for Traversal of Network Address 797 Translators" by M. Komu et al. Internet-Draft, IETF, June 2009, work 798 in progress. 800 [24] "HIP Experimentation using Teredo" by R. Moskowitz. HIPRG in the 801 IETF, June 2008. http://www.ietf.org/proceedings/08jul/slides/HIPRG- 802 3.pdf 804 [25] "RFC 4347: "Datagram Transport layer Security" by E. Rescorla et 805 al. IETF, April 2006. 807 [26] Framework for Establishing an SRTP Security Context using DTLS 808 by J. Fischl et al. Internet-Draft , March 2009. To be published as an RFC. 811 [27] Datagram Transport Layer Security (DTLS) Extension to Establish 812 Keys for Secure Real-time Transport Protocol (SRTP) by D. McGrew and 813 E. Rescorla. Internet Draft, February 2009, work in progress. 815 [28] "ZRTP: Media Path Key Agreement for Secure RTP" by P. Zimmermann 816 et al. Internet-Draft, IETF, March 2009, work in progress. 818 [29]"Change Process for SIP" by J. Peterson and C. Jennings. 819 Internet-Draft, IETF, February 26 2009, work in progress. 821 [30] Toward 2 exp(W), Beyond Web 2.0" by T.V. Raman. Communications 822 of the ACM, February 2009, Vol. 52, No.2, p. 52-59. 824 [31] A convenient starting point for information on Rich Internet 825 Applications can be found at 826 http://en.wikipedia.org/wiki/Rich_Internet_Applications 828 Author's Addresses 830 Henry Sinnreich 831 Adobe Systems, Inc. 832 601 Townsend Street, 833 San Francisco, CA 94103, USA 834 Email: henrys@adobe.com 836 Alan B. Johnston 837 Avaya 838 Saint Louis, MO, USA 839 Email: alan@sipstation.com 841 Eunsoo Shim 842 Avaya Labs Research 843 233 Mount Airy Road 844 Basking Ridge, NJ 07920 USA 845 Email: eunsooshim@gmail.com 847 Kundan Singh 848 Columbia University Alumni 849 1214 Amsterdam Ave., MC0401 850 New York, NY, USA 851 Email: kns10@cs.columbia.edu 853 Acknowledgment 855 Funding for the RFC Editor function is provided by the IETF 856 Administrative Support Activity (IASA).