Your analogy is flawed anyway. The conference DID workarounds are
invisible to the end user in that they don't have to worry or think
about how they dial the conference bridge. The attended transfer
"workaround" (if you want to call it that) requires end users to make a
conscious decision about how they are transferring the call which is
almost never going to happen no matter what kind of environment you work
in. End users expect that if they can press the buttons on the phone
that it will work.
Plus there is a very valid argument about doing an attended transfer to
a user who does not answer, then completing the attended transfer to
that users voicemail.
In any case Tony just found http://jira.freeswitch.org/browse/SFSIP-86
which supposedly fixes the issue. I hope to see it soon in sipX. Perhaps
this will also make other FreeSWITCH features available to sipX as well,
such as valet parking
http://wiki.sipfoundry.org/display/xecsuserV4r2/Custom+FreeSWITCH+programming
BTW everyone let's not get mad at each other (which I don't think anyone
is...). Disagreements occur all the time and I think it's healthy for
the project when they're fleshed out on the list.
On 07/18/2010 01:50 PM, Todd Hodgen wrote:
Set expectations. You can't do a supervised transfer to Auto
Attendant or Voicemail in the system today. It's true, it's accurate,
it's an expectation you need to set for the end users. You can dance
around this all you want, but it doesn't change the fact that it isn't
supported. Yes, it should be there, and there is a very limited use
case for it. Bottom line, it's not there.
Last I saw there is no way to set a DID to a conference bridge. It
should be there. However, we set the expectation that it's not there,
or there is a workaround for it.
Find one phone system that has everything, has no bugs, and has every
feature that people desire. It doesn't exist. They need to do a
blind transfer. That is why account managers, sales engineers and
customer service representatives have to set the correct expectations
with the end users.
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of *Josh Patten
*Sent:* Sunday, July 18, 2010 10:27 AM
*To:* [email protected]
*Subject:* Re: [sipx-users] Help with Patton gateway
I only run 550's and 650's.
I really don't think speculating about ways for end users to "work
around" the problem is very constructive. As Tony and I have both said
this is a major flaw that should be fixed and I have a feeling it's
going to take a while due to having to wait for FreeSWITCH upstream to
fix it, and the fact that sipX generally stays at least a point
version behind on FreeSWITCH doesn't help things.
The more of these major bugs I find, the more my end users are going
to start wondering why I switched them over from the old system.
These are the major/critical issues I've run into over the last month:
http://track.sipfoundry.org/browse/XX-8438
http://track.sipfoundry.org/browse/XX-8646 - My coworker is almost
finished with this fix
http://track.sipfoundry.org/browse/XX-8652
On 07/18/2010 10:31 AM, Jim Canfield wrote:
On Sat, Jul 17, 2010 at 7:09 AM, Michael Scheidell
<[email protected] <mailto:[email protected]>> wrote:
I suppose we could just train everyone to push that extra 'more'
button and hit blind transfer.
In fact, an attended transfer to AA or VM doesn't make all that much
sense anyway.
For your Polycom 320/335's you can make blind transfer the default
behaver. Not that that offers much of a solution, just thought I would
throw that out for those users who do have them.
_______________________________________________
sipx-users mailing [email protected]
<mailto:[email protected]>
List Archive:http://list.sipfoundry.org/archive/sipx-users
Unsubscribe:http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX --http://www.sipfoundry.org/
_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/
