> 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, which is relatively simple to implement. The second part is "inbound call management", and using it for callback-on-busy is only on instance. The two problems might be as easily solved independently. Although I'd like to hear what sort of situation would generate such a heavy amount of callback-on-busy demand. > - 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. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
