The reason why this is an issue is because for end users migrating from another system, as in my case, They are used to the "Transfer->dial number->Transfer" method of transferring calls. The "Transfer->Blind->Dial Number" concept is foreign to them so out of force of habit they use the former method for transferring all calls.
On 07/16/2010 06:53 PM, Paul Herron wrote: > I concur with Matt's last two posts. I just tested attended transfer as > described and had the same results -- fine to VM, failed to AA. Blind > transfers are fine. Running 4.0.4 w/Polycom 650 3.1.3c split, BootROM > 4.2.2 > > Of course, one might wonder why we need an attended transfer to AA > (other than the user screwing-up and pressing the wrong button -- o.k., > I guess that's a pretty good reason). > > I also just tested attended transfer of an external call (via SipBridge) > and had the same results -- fine to VM, failed to AA. Blind is fine. > > -----Original Message----- > From: Matthew Kitchin (public/usenet) [mailto:[email protected]] > > Sent: Friday, July 16, 2010 6:44 PM > To: [email protected] > Subject: Re: [sipx-users] Help with Patton gateway > > Attended for everything in what I described below. > Blind is fine. > > On 7/16/2010 5:41 PM, Josh Patten wrote: > >> Attended transfer to VM or blind? >> >> I haven't seen any issues with blind transfer. >> >> On 07/16/2010 05:32 PM, Matthew Kitchin (public/usenet) wrote: >> >> >>> A little more info, 4.0.4 seems fine when transferring to someone's >>> > VM, > >>> but fails when transferring to Auto attendant. IT totally fails going >>> > to > >>> the AA. >>> 4.2.1 seems to exhibit the same behavior (described below) when >>> transferring to either VM or AA. >>> >>> On 7/16/2010 5:15 PM, Matthew Kitchin (public/usenet) wrote: >>> >>> >>> >>>> I just tested. I think I'm seeing the same thing. >>>> On 4.2.1, if I do attended transfer to the auto attendant, the call >>>> tranfers, but appears to stay on hold on the transferring phone. >>>> On 4.0.4, it appears to be even more broken. The call stays on hold >>>> and it doesn't actually transfer the call either. >>>> >>>> I"m using Sipxbridge and polycoms with 3.1.3 >>>> >>>> On 7/16/2010 5:06 PM, Josh Patten wrote: >>>> >>>> >>>> >>>>> Can I get other people on this list to test this scenario as well? >>>>> > It'll > >>>>> only take a couple of minutes. I know all of you have at least two >>>>> phones on your desk :-P >>>>> >>>>> Josh Patten >>>>> Assistant Network Administrator >>>>> Brazos County IT Dept. >>>>> (979) 361-4676 >>>>> >>>>> >>>>> On 7/16/2010 4:55 PM, Tony Graziano wrote: >>>>> >>>>> >>>>> >>>>>> I hope its fixable with a config change and not a deep down inside >>>>>> issue. >>>>>> ============================ >>>>>> Tony Graziano, Manager >>>>>> Telephone: 434.984.8430 >>>>>> Fax: 434.984.8431 >>>>>> >>>>>> Email: [email protected] >>>>>> >>>>>> LAN/Telephony/Security and Control Systems Helpdesk: >>>>>> Telephone: 434.984.8426 >>>>>> Fax: 434.984.8427 >>>>>> >>>>>> Helpdesk Contract Customers: >>>>>> http://www.myitdepartment.net/gethelp/ >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: [email protected] >>>>>> <[email protected]> >>>>>> To: [email protected]<[email protected]> >>>>>> Sent: Fri Jul 16 17:49:46 2010 >>>>>> Subject: Re: [sipx-users] Help with Patton gateway >>>>>> >>>>>> I'm only talking about attended transfers to FreeSWITCH media >>>>>> > services > >>>>>> (AKA conference, voicemail, and auto attendant) not phone-to-phone >>>>>> transfers. Phone-to-phone transfers are working fine. >>>>>> >>>>>> Josh Patten >>>>>> Assistant Network Administrator >>>>>> Brazos County IT Dept. >>>>>> (979) 361-4676 >>>>>> >>>>>> >>>>>> On 7/16/2010 4:48 PM, Michael Scheidell wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 7/16/10 5:45 PM, Josh Patten wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I'm running 4.2.1 >>>>>>>> >>>>>>>> I have just confirmed this has issues with Aastra phones as >>>>>>>> > well. > >>>>>>>> I've been saying for a while that FreeSWITCH has issues with the >>>>>>>> > way > >>>>>>>> attended transfers are handled. >>>>>>>> >>>>>>>> > http://wiki.sipfoundry.org/display/xecsuserV4r2/Custom+FreeSWITCH+programming > >>>>>>>> is a prime example. >>>>>>>> >>>>>>>> Fix the FreeSWITCH SIP stack and these issues will probably go >>>>>>>> > away. > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> attended transfers: >>>>>>> cisco to cisco is ok (sipx 4.2.0) (but funky.. you see the call >>>>>>> > drop, > >>>>>>> the screen go blank, and then the calls start to go again) >>>>>>> cisco to polycom, doesn't work at all. >>>>>>> >>>>>>> (* just do you don't complain about me using cisco's.. looks like >>>>>>> > its > >>>>>>> the FreeSWITCH SIP stack) >>>>>>> >>>>>>> -- >>>>>>> Michael Scheidell, CTO >>>>>>> Phone: 561-999-5000, x 1259 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> *| *SECNAP Network Security Corporation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> * Certified SNORT Integrator >>>>>>> * 2008-9 Hot Company Award Winner, World Executive >>>>>>> > Alliance > >>>>>>> * Five-Star Partner Program 2009, VARBusiness >>>>>>> * Best in Email Security,2010: Network Products Guide >>>>>>> * King of Spam Filters, SC Magazine 2008 >>>>>>> >>>>>>> >>>>>>> >>>>>>> > ------------------------------------------------------------------------ > >>>>>>> >>>>>>> This email has been scanned and certified safe by SpammerTrap. >>>>>>> For Information please see >>>>>>> > http://www.secnap.com/products/spammertrap/ > >>>>>>> >>>>>>> > ------------------------------------------------------------------------ > >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> 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/ >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> 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/ >>> >>> >>> >> _______________________________________________ >> 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/ >> >> > > > _______________________________________________ > 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/ > _______________________________________________ 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/
