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
