On Sep 27, 2005, at 2:02 PM, Francois Audet wrote:
I think a missed call package is a decent idea.
I've been pondering something similar in the scope of residential
primary line service definition in another SDO, and one of the
approaches that has been suggested is the use of a "network event
package" that could do things like tell a subscriber:
* A call was sent to your AOR but answered at another Contact:
* A call was sent to your AOR, but since you have diverted all calls to
voice-mail, it was sent there.
* A call was sent to your AOR as a result of a forwarding operation
applied to a transferred call in a partner network, was rejected from
your voice mail server for lack of a compatible codec, and has been
diverted to a small pub in East Anglia that we thought you might be at.
* A call was sent to you AOR, and forked to your contacts, one of which
replied with a "busy everywhere" response causing us to reject the
call. Perhaps you should check into it.
That is to say, perhaps such a package could reflect both 1) processing
decisions made by a serving proxy for an AOR in response to a request,
2) history information contained in that request, especially if such
information is used in the processing of the request, and 3) history
information gleaned from processing of the request in other nodes on
alternate paths "downstream" from the proxy.
So in addition to being able to give a you a missed call summary (ala
the old Teltier 2g application by that name), this package could also
issue the logical equivalent of the "splash rings" that Class 5
switches send when they've diverted a call away from a subscriber line
as a result of call forwarding. Or it could tell employee Bob in the
call center that fellow employee Alice just took a call, and that she's
taken the last three calls for the call center, and perhaps he should
finish his tea and get back to work before Alice comes looking for him
with a tire-iron in hand. Seems like a useful bit, eh?