Scott Lawrence wrote:
> 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.
>
Yes I agree it would be confusing. The patch I have added to the issue
(to be committed by Joe) removes the user-forwarding URL parameter when
inviting a third party to conference.
However user-forward=false is still set for "click to dial" because the
control goes to the calling party first, who is, presumably right by his
phone.
Of course, we could remove it in that case too if so desired ( please
voice an opinion ).
Use case: I could, with this facility place calls from my PBX phone even
when I am traveling by setting up call forwarding forwarding to my cell
phone. Log into sipxconfig, enter the desired number and click to dial.
My cell phone rings, I pick up. Then the called party rings but the call
is placed by sipx ( and hence uses the sipx configured trunk gateway ).
> 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.
>
>
>
Agreed. We would have to make a provision for a customized announcement
per conference. It is pretty confusing to pick up the phone and suddenly
you are in conference without warning. It would take a bit of work to
accomplish this but I believe we can use the automatic attendant to play
a conference-specific prompt and transfer the call.
Ranga
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
