On Mon, 2009-02-02 at 16:03 -0500, M. Ranganathan wrote:

> 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 ).

Leave click-to-dial as is for now.

Woof adds:


> NO.
> 
> Due to Shared line apperances, multiple-registrations, etc.  
> 
> Only ONE phone should ring, no forking, no forwarding, no Q values.

Note that this is not what you have now ... if the AOR appears on
multiple lines (my line on my [non-existant] assistants phone, for
example), then it's going to ring on all of them at once.  Blocking
aliases doesn't help, because those are all registrations.

This is why we really need semantic tagging of contacts, and ideally why
we might also want to associate tag values with registrations (in this
case, we could do it by actually configuring a slightly different
version of the AOR for different line appearances).

Re: the user experience...

> 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 ).

That's an interesting case, but not the same as what we have... let's
leave it for the future (have to have something in the next
version :-) ).

> > 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.

Well, the auto-attendant already (at least has the provision for) name
recordings, so we could assemble the message I suggested above without
requiring any new configuration.


_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to