San Jose meeting report AVD-2586
okubo at MXZ.MESH.NE.JP
Wed Oct 6 23:30:24 EDT 2004
In a message dated 9/27/2004 5:17:15 PM Eastern Standard Time,
lilo at 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
- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sg16-avd