Hi Dale,
I agree with your analysis for the most part. However, in case of an end-point with no support or notion of this feature my original issue / question still remains: How can the user indicate he wants to use this feature? And before that, the other question is: how does the user learn about the availability of this feature?
As you say, a proxy could perform UA operations on its behalf in a way that is almost compatible with end-to-end operation except for one important issue: end-user consent. Service logic executed at the UA could simply ask the user or have a configurable policy, a proxy cannot do this (at least, to my knowledge not in a way currently defined by SIP standards). So my idea was that there could be a standards defined way for the UA to discover this, such that it "knows how to look for the advertisement" as you say. In case of callback-on-busy such mechanism would e.g. piggyback on the busy response + ACK as I indicated, but there are other options
It seems my choice of example feature (callback-on-busy) has moved the discussion away from the underlying topic I initially wanted to talk about. I am however interested in both
Thanks all for your contributions so far,
Jeroen
----- Original Message ----- From: "Dale Worley" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 13, 2005 7:56 PM
Subject: RE: [Sip-implementors] Callback-on-busy and proxy-supportedfeatureannouncement in general
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
