Call Completion Implementation Details

The call-completion architecture augments each caller's UA (or UAC) which wishes to be able to use the call-completion features with with a "call-completion agent". An agent may be associated with more than one UA if it is common that a caller or population of users will be shared between the UAs, and especially if the UAs share an AOR. The caller's agent has a method of monitoring calls made from the UA(s) in order to determine their Call-Id's and (potentially) their final response statuses. This may be achieved by subscribing to the dialog event package of the UA(s) or by other means. The callers using the UA(s) can indicate to the caller's agent when they wish to avail themselves of CC for a recently-made call which failed to reach their chosen destination. This may be achieved by an INVITE to a special URI which is routed to the caller's agent or by other means. The caller's agent has a method of monitoring the status of the UA(s) to determine when they are available to be used for a CC call. This may be achieved by subscribing to the dialog event package of the UA(s) or by other means. The caller's agent can communicate to the UA(s) that CC has become active and to inquire if the relevant calling user is available for the CC call. This may be achieved by sending an INVITE to the UA(s) or by other means. The caller's agent can order the UA(s) at which the relevant calling user is available to generate a CC call to the callee. This may be achieved by sending a REFER to the UA(s) or by other means.

The call-completion architecture augments callee's UA (or UAS) which wishes to be able to be the target of the call-completion features with a "call-completion monitor". A monitor may be associated with more than one UA if it is common that a callee or population of users will be shared between the UAs, and especially if the UAs share an AOR. The callee's monitor has a method of monitoring calls made to the UA(s) in order to determine their Call-Id's and (potentially) their final response statuses. This may be achieved by subscribing to the dialog event package of the UA(s) or by other means (e.g., by communication with the UA's "home proxy"). The callee's using the UA(s) may be able to indicate to the callee's monitor when they wish to receive CC calls. This may be achieved by an INVITE to a special URI which is routed to the callee's monitor or by other means. The callee's monitor has a method of monitoring the status of the UA(s) to determine when they are in a suitable state to receive a CC call. This state may vary depending on the type of CC call in question. E.g., a UA is available for CCBS when it is not busy, but a UA is available for CCNR when it becomes not busy after being busy with an established call. This monitoring may be achieved by subscribing to the dialog event package of the UA(s) or by other means. The callee's monitor maintains information about the set of INVITEs that have been received by the UA(s) that did not obtain successful final responses. In practice, the monitor may remove knowledge about an incoming dialog from its set if its CC policy establishes that the dialog is no longer eligible for CC.

The caller's UA sends an INVITE to a request URI. One or more forks of this request reach one or more of the callee's UAs. By hypothesis, none of the callee's UAs returns a success response, as otherwise, call completion services would not be needed for this call. However, the caller's INVITE might succeed at some other UA that the calling user considers insufficient to satisfy his needs. E.g., a call that is not answered by the callee user may connect to the callee user's voicemail server. Eventually, the INVITE fails, or the resulting dialog(s) are terminated. Note that the Call-Id of the INVITE is a unique identifier of this call attempt. The caller's agent records the request URI, the Call-Id, and possibly the final request status that the caller's UA received. The callee's monitor records the Call-Id and possibly the final request status(es) returned by the callee's UA(s). Note that the caller's UA may not receive any response from any of the callee's UA(s), as the final response returned to the caller's UA may have been from a fork that reached a UA that was not the callee's.

The calling user indicates to the caller's agent that he wishes to invoke call-completion services on the recent call. Note that from the SIP point of view, the INVITE may be successful, but from the user's point of view, the call may be unsuccessful. E.g., the call may have connected to the callee's voicemail, which would return a 200 status to the INVITE but from the caller's point of view is "no reply". Question: At this point, it seems that the best choice is that the caller's agent need not determine what type of CC is being requested (CCNR vs. CCBS), as (1) it cannot determine this from the INVITE final response, (2) it would be a burden to make the calling user to specify it, and (3) the callee's monitor can determine this from the responses returned by the callee's UAs. The caller's agent subscribes to the call-completion event package using the request URI of the original call. This SUBSCRIBE should be routed in much the same way as the original INVITE, but ultimately being routed not to the callee's UAs but to the callee's monitor. The Event header of the subscribe specifies the call-completion event package with a parameter "call_id=[Call-Id of the original call]". Question: Should the specification of the original call be done in the SUBSCRIBE body rather than in an event-param? The SUBSCRIBE should have headers to optimize its routing. In particular, it should contain "Request-Disposition: parallel, no-cancel", and an Accept-Contact header to eliminate callee UAs that are not acceptable to the calling user. The callee's monitor(s) that receive the SUBSCRIBE establish subscriptions. These subscriptions represent the caller's agent's request for call-completion services. The callee's monitor must be prepared to receive multiple forks of a single SUBSCRIBE, and should respond 482 (Merged Request) to all but one fork. The callee's monitor must be prepared to receive SUBSCRIBEs regarding original calls that it has no knowledge of, and should respond 404 (Not Found) to such SUBSCRIBEs. The monitor may apply additional restrictions as to which caller's agents may subscribe. The caller's agent must be prepared to receive multiple responses to the SUBSCRIBE and to have multiple subscriptions established. The agent must also be prepared to have the SUBSCRIBE fail, in which case, CC cannot be invoked for this original call. The call-completion event package returns various information to the caller's agent, but the vital datum is that it contains an indication whether the callee's monitor has chosen the caller's agent to perform the next CC call to the callee. This datum is initially false.

The continuation of the caller's agent's subscription indicates that the caller's agent is prepared to initiate the CC call when it is selected by the callee's monitor. If the caller's agent becomes unwilling to initiate the CC call (e.g., because the calling user has deactivated CC or because the caller's UA becomes busy), the caller's agent must terminate or suspend the subscription(s). (Currently, no method of suspending a subscription is defined.) If the caller's agent later becomes willing again to initiate CC for the original call, it may resume the suspended subscription(s) or initiate new one(s). If the callee's monitor becomes aware that, according to its policy, the original call referenced by a subscription will never be selected for call-completion, it should terminate the subscription. (And respond to any attempt to start a new subscription for that original call with 404.)

The callee's monitor has a policy regarding when and how it selects CC requests to be activated. This policy may take into account the type of the requests (CCNR vs. CCBS), the state of the callee's UA(s), the order in which the original calls arrived, and any previous CC attempts for the same original call. Usually the callee's monitor will choose only one CC request for activation at a time, but if the callee's UA(s) can support multiple calls, it may choose more than one. The callee's monitor changes the "call completion active" datum for the chosen caller's agent from false to true. This triggers a notification for the agent's subscription. The agent receives the notification with the CC active datum set to true. It then terminates or suspends all other CC subscriptions for this original call, and all CC subscriptions for all other original calls, in order to prevent any other CC requests from this caller from being activated. The agent then determines whether the calling user is available for the CC call, usually by calling the caller's UA(s). If the calling user is not available, the caller's agent indicates this to the callee's monitor by terminating the CC subscription. If the calling user is available, the caller's agent causes the caller's UA to initiate a call to the request URI (which is expected to be routed to the callee's UA(s)). Question: Should the callee's monitor supply a URI which should be used in the CC call? This seems like it would be more reliable, as the monitor is probably "for" a particular callee URI, and it has no information about the destinations of any other forks of the original call. Question: The CC must be marked in some way as a CC call in order for the callee's monitor to know that the CC activation is being acted upon by the caller's agent. And the marking must include the original Call-Id to allow correlation with the original call. Possibilities for a marking are a special URI-parameter on the request URI or a special header. The callee's UA(s) and any associated proxies may give the CC call precedence over non-CC calls. The callee's monitor supervises the receiving of the CC call. If the CC call does not arrive at the callee's UA(s) promptly, the monitor will withdraw CC activation from the caller's agent by changing the value of its CC active datum to false. Similarly, if the CC call fails, the monitor will withdraw CC activation. Depending on its policy, the same original call may be selected again for CC activation at a later time. If the CC call succeeds, the monitor will also withdraw CC activation, but the original call will never again be selected for CC activation (and in practice, can be deleted from the monitor's records). Question: Is that last statement true? Can a call appear to succeed from the monitor's point of view but fail from the calling user's point of view? Once the CC call has failed, or if it has succeeded, once the CC call has been terminated, the callee's monitor's policy may select another CC request for activation.

Question: What format should the event package data be presented in? proposes a simple attribute-value format. We might also consider yet another XML format. The only necessary information to be provided by the call-completion event package is the CC activation datum, whose value is false (meaning that this CC request has not been chosen for activation) or true (meaning that it has). Question: If we decide to let the callee's monitor provide the request URI for the CC call, that request URI should probably be a mandatory datum as well. The event package may provide information about the callee's monitor's policy. In particular, the PSTN CC feature gives an indication of the "service retention" attribute, which indicates whether the CC request can be continued to a later time if the call-completion call fails due to the callee's UA(s) being busy. If the callee has a caller-queuing facility, we want to treat the call-completion queue as part of the queuing facility, and include in the event package information regarding the state of the queue, such as number of callers ahead of this caller and expected wait time. In that case, this data should probably not trigger a notification every time it changes, but rather at suitable time increments.