It seems like incoming call management could be done in several ways that are within the current standards:
1. The publisher for dialog events could just lie to a suitable set of potential callers -- by appearing to be non-busy to only one subscriber, it can select which subscriber will call. 2. An incoming call manager can accept multiple INVITEs and then transfer them one by one to the real UA. Since the queued dialogs would have no media, the network overhead would be low, but the calls would appear to connect, which makes any call detail records incorrect. 3. Closer to the SIP philosophy would be for the call manager to response 182 Queued to all INVITEs that it will not admit at the moment. When a call reaches the front of the queue, it can transfer it to the phone, where it will receive 183 Ringing and connect. There are some complications -- An INVITE must be accepted or rejected within about 32 seconds, so if a call is queued for about 30 seconds, the manager should reject it with 486 Busy. The caller's callback-on-busy function will then wait for a SUBSCRIBE to the phone to again indicate that it is not busy, and send another INVITE. And the call manager must realize that the second INVITE is a continuation of the first, but it can detect that by noticing that the From: addresses are the same. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
