Dale Worley wrote:
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
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:
Looking over your requirements, I think it might be helpful to divide the problem into two parts. The first is vanilla callback-on-busy,
right.
which is relatively simple to implement.
Maybe, maybe not, depending on what you think the requirements are.
The second part is "inbound call
management", and using it for callback-on-busy is only on instance.
Yes.
The two problems might be as easily solved independently.
This is a reasonable approach. But at the same time it is worth considering how the two interact.
Although I'd like to hear what sort of situation would generate such a heavy amount of callback-on-busy demand.
Any time there is a number that gets a lot of inbound traffic, and yet doesn't have automated call treatment, you can get into a situation where it is hard for callers to get through. If the callers have the option of callback-on-busy then you could get a lot of it, because it is more convenient for the caller than just repeatedly dialing the phone.
- 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.
I think that this can be solved by restricting the information that is available in the dialog event notices to un-authorized subscribers. For instance, it is possible to construct a dialog event package that tells that the phone is being used without disclosing any details about that use.
Yes, this is RECOMMENDED in the dialog package, so while it isn't required it may be sufficient for this application.
What this doesn't do is provide fairness. If multiple potential callers are subscribed, when the callee ceases being busy they will presumably all be notified more-or-less concurrently. Then it becomes a race to see which one can call back first. And not only are they racing with one another, they are also racing with any other callers that just happen to call at that time.
This then gives the advantage to caller's whose UAs follow particular strategies:
- A UA that calls immediately after getting the notification has the advantage over one that notifies the calling user first.
- A UA that "repeat dials" as fast as possible may have the advantage over any that uses the dialog package, because it can get in after the callee ceases being busy, but before any of the watchers receive the notification.
This is especially problematic in the common case where the calling user wants to hang up and do something else while waiting. In this case, the calling UA SHOULD alert the calling user before placing the call, because otherwise it might bother the callee when the caller is no longer available. But this puts the caller at a distinct disadvantage rather than other waiting callers whose UAs don't work this way.
None of this matters much in situations of low call volume, so it is probably one good trick in the bag of tricks for this function.
Paul _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
