On Mon, 2009-02-02 at 15:27 -0500, M. Ranganathan wrote:
> On Mon, Feb 2, 2009 at 2:08 PM, Scott Lawrence
> >> >> Or we simply allow forwarding and live with the expected consequences
> >> >> of doing so as you state above.
> >> >>
> >> >> Any ideas on which direction is best? I would vote for #1 as I would
> >> >> not want for my secretary to attend conferences ( especially because I
> >> >> do not have one :-) ).
> >> >>
> >> >
> >> > My general rule is "the call must go through", so I'd choose to allow
> >> > alias-based forwarding. This may result in some interesting failure
> >> > modes, but they are failure modes that a human can figure out ("oh...
> >> > you wanted Bob but he has his phone forwarded to me today") as opposed
> >> > to the current "it broke" situation.
> >> >
> >> >
> >> >
> >> Another option would be a checkbox in the sipxconfig screen that
> >> indicates whether or not call forwarding is allowable on the INVITE.
> >> This way, if a user selects it he is aware that the call may be
> >> forwarded on the INVITE
> >
> > Non-starter, I'm afraid - you're a developer on the project, and _you_
> > didn't understand the implications.
> >
> >
> >
>
> I don't follow. If the flag is set, then I put "dont forward" on the
> request URI in which case you have to use the u...@domain in the entry
> box. If the flag is not set I use "forward" on the request URI. Kindly
> explain why this does not work? Also please note that your analysis of
> the issue is not quite right in JIRA. You can indeed invite third
> party to confences when logged in as administrative user.
The point is that when you entered the users phone number, you didn't
think you were forwarding - you thought that you were using the direct
number, but that was not true. The number was an alias that went to the
user name - most users (normal humans who use telephones) will have no
idea that the real address is not the phone number and will not expect
"don't forward" to break it, but if the system is set up this way (and
some are), it will not work. More importantly, there is no diagnostic
information returned - no clue at all _why_ it did not work, and (as you
discovered), it works just fine if you pick up a phone and dial.
You'd be providing a control for a deep aspect of the system that the
user doesn't (and should not need to) understand. It's at best
confusing and as often misleading.
Woof was right - take the user-forward attribute off and send the
INVITE. If it forwards to the wrong person, they'll figure out why and
all will be well.
I think that the user experience for the invited party is pretty bad...
if I am invited to a conference, my phone rings and I answer and am
immediately in the conference. The experience might not be so great for
the other parties in the conference either - suppose my phone is
forwarded to my home number and my 4 year old daughter answers (or my
home answering machine)?
Really I should get some announcement that this is a conference invite
"This is a conference call invite for <invited-user-name>; you have been
invited by <inviting-user-name>; press 1 to enter the conference or hang
up to disconnect", and it should time out after a few seconds if the
DTMF 1 is not sent.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
