A New Forking Mechanism for Gathering and Distributing Information

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: the request is forked immediately (parallelly) to all targets, regardless of the "q" values of the UASs, the request is forked to all applicable UASs, even after one UAS has accepted the request, and 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.

The rules for SIP proxies in RFC 3651 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.

The currently specified behavior for proxies is less useful in many situations other than an ordinary INVITE.

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.

The PUBLISH and SUBSCRIBE 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.

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 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.

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.

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. 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.

Many "messaging" applications would be better served by forking to all available UASs than by the current forking mechanism. The MESSAGE 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 AOR, as the UAs are likely to store them for later retrieval by the user. Similarly, a UA that supports MSRP messaging protocol 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.

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: 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. A proxy does not send CANCELs to other legs of the fork when one leg returns a 2xx response. 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 () 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.

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 .) 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 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.