Dale,
I agree with your philosophy. But callback-on-busy is a tough problem, and one for which its not clear that all agree on the requirements. I will suggest a few possible requirements:
- if several UACs are attempting callback-on-busy to the same target, then in the absence of other policy they should be serviced is fifo order.
- when multiple callers are attempting to call the same target, using callback-on-busy should not reduce the the chances of getting through as compared to simply retrying INVITE continuously.
- it should be possible for a sufficiently capable UA that is the target of callback-on-busy requests to control the order in which they are served
- the target of a callback-on-busy is an AOR with multiple registered contacts, then the callback should be attempted as soon as one suitable contact becomes unbusy.
- if A is permitted to call B, then a should be able to do callback-on-busy to B. It should not require special privileges that are normally only granted to those with a special relationship to the target.
Another requirement that might be considered is
- must interoperate with PSTN (I think that requirement is in conflict with the others.)
The "subscribe to dialog package" approach doesn't deal with any of these. Of course you may disagree that those are requirements, but they seem like reasonable requirements to me. Dealing with the differences in privilege, and the need for fifo queing, suggests to me that some new mechanism is needed.
The work queue is still pretty full in sipping, but I think this is worthy of being added to that work queue at some time, though maybe not yet.
Paul
Dale Worley wrote:
Let's look at this problem from a different philosophy, and its aplication to the specific case of callback-on-busy.
SIP generally works better with an endpoint-driven ("end-to-end") solution whenever possible. So for callback-on-busy, the caller's UA, upon receiving 486, would send a SUBSCRIBE to the callee's UA, and wait for all dialogs at that UA to terminate. Then it would initiate the callback operation.
This requires that the caller's UA support a callback-on-busy operation, and that the callee's UA support the dialog event package.
We need no mechanism for a proxy to indicate is special capabilities, as it does not participate in any essential way. As a free side-effect, callback-on-busy works across the entire Internet, not just within one organization. The Supported: and Allow-Events: headers in the reply to OPTIONS allows a UA to indicate its capabilities.
Within this context, the proxy only performs tasks that cannot be done by the UAs. For example, routing, access control, billing, and registration of dynamically located entities, all of which are essentially transparent (if an action is permitted at all).
The proxy can also perform UA operations on behalf of UAs that are not capable of them. The standard case is a proxy that Record-Routes itself for all calls to a UA and handles dialog event package subscriptions on behalf of the UA. In sipX, the proxy similarly performs call pick-up actions for UAs that cannot execute them themselves. (See the "SIP-B" documentation.) But these activities are compatible with the end-to-end philosophy because they use only standard SIP features on their "outside" side.
In the case of callback-on-busy, the operation can be done entirely in the caller's UA (or in a proxy acting on its behalf), using only standard SUBSCRIBE/NOTIFY operations on the network. But if the UA cannot do it, a nearby proxy could perform callback-on-busy on its behalf.
Within this framework, there is never any need for a proxy to advertise special features. (A proxy would only be providing special feature support to a UA which doesn't have that feature, and then how would the UA know to look for the advertisement?)
On the other hand, since the proxy can assist UAs without the feature, users do not have to upgrade their UAs.
Dale
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
