Also... What if you were transferring hoping the person picked up, it went to their VM, so then you wanted to go ahead and go through with the transfer once their VM picked up. Maybe not the best way to do it, but I'm sure someone will try it. -----Original Message----- From: Josh Patten <[email protected]> Sender: [email protected] Date: Fri, 16 Jul 2010 19:49:08 To: <[email protected]> Subject: Re: [sipx-users] Help with Patton gateway
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/ _______________________________________________ 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/
