In a message dated 9/27/2004 5:17:15 PM Eastern Standard Time, lilo@nullpointer.de writes:
[MAP] Anyway, here again, the desire is to prevent an answering machine/voicemail system from answering, which I understand. It is not to prevent forwarding. If I am one of the intended recipients of such as service, I may activate Call Forwarding Unconditional or Busy because I want such calls forwarded to where I am or to another phone on my desk.
Certainly, in this case we'd like to prevent the call from going to a voicemail system. In my book however, I think that's what "Call Forwarding" really is: When I, as the intended recipient of the call, fail to pick up my phone in time, the call somehow is "diverted" or "forwarded" to my voicemail. This may happen by just about any mechanism -- be it H.450.3 or a routing GK playing tricks -- I still
[MAP] No, call forwarding and voice mail are two different services. It just happens that switching systems that do not implement voice mail internally have to use Call Forwarding to send the call to another piece of equipment (like another line) which is the voice mail system. A system can provide voice mail (on no answer or immediately, without calling it "Call Forwarding") just like a system can provide Call Forwarding which is not to voice mail.
In practice, I don't really think there are too many systems not knowing
[MAP} If that were ture, then we should be able to define a parameter as "Don't forward to voicemail" and accomplish exactly what you want.
This assumption, however, doesn't always hold true. Take an alarming system as an example. If this system is triggered, it might systematically call all endpoints in a building and play back an announcement. This system certainly wouldn't bother with following a
[MAP] If I was still in the building with my cell phone, but not where my wired phone is, I would certainly want this warning call forwarded to me! If I was not in the building, I might still want it.
Finally, CDOR might be used to inhibit a call forwarding to external (and thus possibly costly) numbers. This, of course, isn't specified in our document, as in general it's not known, whether a number is external or not. In the future, however, I think such an extension
[MAP} This would be a very useful service, if the calling party would have to pay for the extra cost. And of course the forwarding point must have some concept of what "external" or "long distance" is.
From the meeting report it was clear, that in our draft there was too much control with the calling endpoint. In my previous e-mail I pointed out, that this will be changed to give the "final say" back to the called endpoint. I think, with these changes incorporated into the
What we want to achieve is giving the caller some preference over where the call finally terminates -- without removing any control from the called endpoint or any entity in between. I think, CDOR would be a
[MAP} The fundamental choice is: - If the real control is given to the calling party, then it's "Call Diversion Override". - If the real control is given to the called party, then the service you're defining is "Caller Preferences".
Regarding the "voicemail" topic: Perhaps there really should be a simple service for a voicemail-system to identify itself during call set up.
[MAP] That's exactly what happens today. The caller hears the voice mail prompt and may hang-up.
Don't get me wrong, I think a capability for the calling party to prevent a call being answered by a voice-mail system would be a very useful service.
Mike Pierce