Sipping D.R. Worley Internet-Draft Pingtel Expires: August 27, 2006 February 23, 2006 A New Forking Mechanism for Gathering and Distributing Information draft-worley-sipping-forking-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The rules for SIP proxies are organized so that when a UAC sends an out-of-dialog request, even if the request is forked to a number of UASs, (usually) only one UAS will accept the request, and only the final response from that UAS will be returned to the UAC. This forking mechanism is optimal for an INVITE intended to connect one human user with another human uses, but is poor for requests that have a "one to many" nature, especially PUBLISH and SUBSCRIBE requests, but also including some INVITEs. This document proposes that requests can be marked to specify that they should be forked in Worley Expires August 27, 2006 [Page 1] Internet-Draft A New Forking Mechanism February 2006 a somewhat manner that better supports "one to many" requests. Worley Expires August 27, 2006 [Page 2] Internet-Draft A New Forking Mechanism February 2006 1. Introduction When a UAC sends an out-of-dialog request, it may pass through many proxies, which may fork the request and deliver copies of it to several UASs. The rules for SIP proxies are organized so that (usually) only one UAS will accept the request, and only the final response from that UAS will be returned to the UAC. This process produces results which are optimal for INVITEs, which are intended to connect one human user with another human user. But this process is not optimal in other circumstances, especially SUBSCRIBE and PUBLISH requests, where an automaton UAC wishes to send information to or receive information from a set of automaton UASs. In particular, these requests would perform better if they were forked using a different mechanism: 1. the request is forked immediately (parallelly) to all targets, regardless of the "q" values of the UASs, 2. the request is forked to all applicable UASs, even after one UAS has accepted the request, and 3. all final responses from all UASs are returned to the UAC, rather than being consolidated into one final response. We propose developing a standardized way of marking a request to control how it is forked, so that a UAC can request that it be forked using this alternative mechanism. The issues to be decided are whether such a control marking is desirable in order to enable the alternative forking mechanism, and if so, what the marking should be. Worley Expires August 27, 2006 [Page 3] Internet-Draft A New Forking Mechanism February 2006 2. The current forking mechanism The rules for SIP proxies in RFC 3651 [1] are organized so that for any out-of-dialog request, only one UAS accepts the request and only its final response is received by the UAC. (Within-dialog requests are intrinsically routed to a single destination, the remote target.) In order to accomplish this, various requirements are placed on proxies: One requirement is that if a proxy receives a 2xx response from one UAS to which it has forked the request, it must immediately CANCEL all other forked copies of the request, and send no further copies of the request to other UASs. Another requirement is that a proxy should (normally) consolidate all final responses it receives from UASs into one "best response" to be forwarded to the UAC. The principle that the proxy ensures that only one UAS accepts the request is enforced only approximately -- Due to parallel forking, the request may be sent to two UASs simultaneously, and they may both accept it. If the request method is not INVITE, the proxy will choose one of the responses to send to the UAC and discard the other. If the request method is INVITE, the proxy is required to forward both 2xx responses to the UAC, so that it can be aware that two dialogs were established at the UASs. In that case, the UAC usually sends BYEs to terminate any dialogs beyond the one created by the first 2xx response it receives. This behavior for proxies was specified in RFC 3261 because it is optimal for most INVITEs, which are intended to create a communication path between one human user and another human user. There are problems with this forking mechanism for the establishment of other kinds of communication sessions. Worley Expires August 27, 2006 [Page 4] Internet-Draft A New Forking Mechanism February 2006 3. Problems with the current forking mechanism The currently specified behavior for proxies is less useful in many situations other than an ordinary INVITE. 3.1. Determinism and Diagnosis The current forking mechanism is admirably suited for offloading the work of dealing with the multiple destination UASs to the proxy that is nearest the point of forking. But ipso facto, it hides any failures or unexpected behaviors from the UAC, making it difficult for a human or automaton located at the UAC to diagnose request routing problems without having administrative access to every proxy along the route. (And it is impossible to determine the identity of a proxy that is involved without already having administrative access to the "upstream" proxies.) In addition, because of the "race" between two UASs that are willing to accept the request, the outcome of the request can be non-deterministic. 3.2. PUBLISH The PUBLISH [3] and SUBSCRIBE [2] requests seem admirably suited for an automaton UAC to distribute information to, or retrieve information from, a set of automaton UASs. But the current forking mechanism makes it impossible for the UAC to reliably send one request to all members of a set of UASs that are the forking targets of one URI. This is evident for PUBLISH requests, which carry the information to be disseminated. If the PUBLISH is intended to send information to a particular UA, the request-URI could specify that UA. But there is currently no way to reliably disseminate information to all of the UAs that are the destinations for a particular AOR, all that is guaranteed is that at least one UAS will receive the information.. For most PUBLISH requests, it would be preferable for the request to be distributed to all forking targets, and for all responses from the targets to be returned to the UAC. 3.3. SUBSCRIBE Any method which attempts to gather information from a group of UAs (such as SUBSCRIBE) has similar problems as PUBLISH, but the use of SUBSCRIBE to establish subscriptions at the UASs, which then send NOTIFY requests, makes the situation even messier: Because the method is not INVITE, all 2xx responses are consolidated into one response by the proxies. This often delays the 2xx response until after the NOTIFYs sent by the UASs reach the UAC. In practice, the UAC can only determine the set of subscriptions that it has created by Worley Expires August 27, 2006 [Page 5] Internet-Draft A New Forking Mechanism February 2006 watching for the NOTIFYs that they send. In the prototypical scenario of the pick-up by a user on a phone of a call ringing on another extension, the phone executing the pick-up sends a SUBSCRIBE to the AOR for the extension to be picked up. The proxy forks this SUBSCRIBE to all the phones that have an appearance of the extension, and each UAS phone sends a NOTIFY detailing the early dialogs on that phone. This information enables the executing phone to find the dialog which it must pick up, regardless of the UA on which the dialog is currently ringing. If all incoming calls to that AOR are parallel-forked, all of these subscriptions will return the same set of dialogs, so how the SUBSCRIBE is forked is not important. But if the different UAs for the AOR are serially forked, the dialog will be ringing on only one UA at a time, and it is important that the SUBSCRIBE that is searching for that dialog be forked simultaneously to all of the UAs for the AOR. The current forking mechanism does not make this possible. 3.4. Intercom Another situation in which it would be preferable for all potential targets to receive the request is in an "intercom" feature of an office phone system, where an audio stream is distributed to all the phones in the system, to be output through a speaker on each phone. To implement an intercom request as a single INVITE from the UAC, the single INVITE must be forked to all of targets for request-URI, and the UAC must be able to establish dialogs with all of them. 3.5. Conferencing A more subtle case where connecting to all targets would be useful is the routing of an INVITE generated by a conference system which forks to multiple targets. [4] Sometimes such an INVITE is intended to contact a single human, but at other times, its request-URI routes to many humans, and the intention is to include all of them in the conference. Including multiple respondents in the conference is straightforward to achieve if the forking process allows dialogs to be established with all the UASs, by simply including all of the dialogs in the conference. 3.6. Messaging Many "messaging" applications would be better served by forking to all available UASs than by the current forking mechanism. The MESSAGE [5] request can be used to send SMS-style short messages, and in many cases, it would be preferable to fork them to all UAs for the Worley Expires August 27, 2006 [Page 6] Internet-Draft A New Forking Mechanism February 2006 AOR, as the UAs are likely to store them for later retrieval by the user. Similarly, a UA that supports MSRP messaging protocol [6] as a media session type may be willing to support simultaneous messaging sessions, and so would prefer to issue INVITEs with a meaning much like an INVITE to a voice conference. Worley Expires August 27, 2006 [Page 7] Internet-Draft A New Forking Mechanism February 2006 4. A new proxy forking mechanism Because the current forking mechanism is ideal for single-session INVITEs, it should not be discontinued. But there is a need for a new forking mechanism that can be applied to requests which the UAS wants to establish dialogs with all possible targets. The alternative forking mechanism differs from the current forking mechanism in three ways: 1. A proxy sends simultaneously copies of the request to all targets in the contact set, regardless of whether any have already returned final responses, and regardless of any specified "q" values in any contact set. 2. A proxy does not send CANCELs to other legs of the fork when one leg returns a 2xx response. 3. A proxy returns all final responses to the requester immediately when they are received (much as a stateless proxy would), rather than consolidating them into one response. One possibility would be to have the proxy choose the forking mechanism based on the method of the request. But this is undesirable: (1) It requires every proxy in the signaling path to know the proper treatment of every method that a UAC might send. (2) The example of an INVITE generated by a conference system (Section 3.5) shows that the best processing of requests depends on more factors than just the method. Thus, we need to define a mechanism which a UAC can use mark requests for its desired desired forking mechanism. For upward compatibility, requests which are not marked must be processed as specified in RFC 3261. Requests which are marked for the alternative forking mechanism, but which are forked by a proxy which does not understand the alternative mechanism, will still be processed as in RFC 3261, but that causes no loss of functionality from the current situation. Worley Expires August 27, 2006 [Page 8] Internet-Draft A New Forking Mechanism February 2006 5. Using the new forking mechanism for routing diagnosis TCP/IP networking has evolved a rich set of tools for diagnosing network problems, such as ping, traceroute, nslookup, dig, and telnet. Some of these tools depend on features of the TCP/IP protocol suite that were added to specifically support diagnostics, whereas others exploit the protocol suite in ways not imagined when they were designed. Currently, few diagnostic tools exist for SIP networking other than the OPTIONS request for testing end-to-end connectivity. In particular, it is hard for a UA to trace the routing of a SIP request; tracing usually requires administrative access to the proxies involved. A crude "traceroute" can be made by sending a series of OPTIONS requests with Max-Forwards values starting at one and increasing by one. Each OPTIONS request will be penetrate one step further along the proxy chain before being returned as either a 2xx (OK) or 483 (Too Many Hops) response. (See section 11.2 of [1].) But each step of the process can return only one response (OPTIONS being a non- INVITE request), thus hiding most information about any forking. Using the new forking mechanism, the responses to this series of OPTIONS requests would begin to show the forking that is involved the the request's path, as the responses from each request would span the breadth of the forking at that depth in the routing tree. However, a 483 response is not guaranteed to contain much information about the SIP agent which generated the response, other than its name. Nor is it required to contain much information about the request as it appeared at that agent. In particular, knowing the request-URI from the request at that point would be invaluable, as would knowing the Via headers, which allow the routing tree to be reconstructed automatically. But if SIP agents follow [7] and generate 483 responses that return the headers of the failing request, the collection of 483 responses would provide detailed information about how the request had been routed. 6. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Campbell, B., Olson, S., Peterson, J., Rosenberg, J., and B. Stucker, "SIMPLE Presence Publication Mechanism", Worley Expires August 27, 2006 [Page 9] Internet-Draft A New Forking Mechanism February 2006 I-D draft-ietf-simple-publish-00, February 2003. [4] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", I-D draft-ietf-sipping-conferencing-framework-04, February 2005. [5] Campbell, B., Mahy, R., and C. Jennings, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, February 2005. [6] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol", I-D draft-ietf-simple-message-sessions-10, February 2005. [7] Lawrence, S., Hawrylyshen, A., and R. Sparks, "Diagnostic Responses for SIP Hop Limit Errors", I-D draft-ietf-sip-hop-limit-diagnostics-00, February 2006. Worley Expires August 27, 2006 [Page 10] Internet-Draft A New Forking Mechanism February 2006 Author's Address Dale R. Worley Pingtel Corp. 400 West Cummings Park, Suite 2200 Woburn, MA 01801 US Phone: +1 781 938 5306 x173 Email: dworley@pingtel.com URI: http://www.pingtel.com Worley Expires August 27, 2006 [Page 11] Internet-Draft A New Forking Mechanism February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Worley Expires August 27, 2006 [Page 12]