So just give everyone a full circle look at this, after a total 3 month TAC case, pushes from Ryan, Wes, Matt Taber, and especially help from Brian Meade, it was determined that this is as designed. User Control Single Number reach is not supposed to work with Blind Transfers. I am getting an enhancement request opened and in the meantime they are going to try to make the documentation clearer for the benefit of others.
Thus ends my saga! Thanks again to everyone that helped. Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518 fax. 410.252.9284 Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830 From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Matthew Loraditch Sent: Tuesday, January 14, 2014 1:33 PM To: Erick Wellnitz; Wes Sisk (wsisk) Cc: cisco-voip voyp list Subject: Re: [cisco-voip] SNR/Mobility Not Working for Transferred Calls with User Control DTMF works for all other functions at this client. User Control for non-transferred calls and everything involving Unity Connection. I also have CCX and it works there. Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518 fax. 410.252.9284 Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830 From: Erick Wellnitz [mailto:ewellnitzv...@gmail.com] Sent: Tuesday, January 14, 2014 1:27 PM To: Wes Sisk (wsisk) Cc: Matthew Loraditch; cisco-voip voyp list Subject: Re: [cisco-voip] SNR/Mobility Not Working for Transferred Calls with User Control An easy way to test if DTMF is correct is to call into VM from outside and see if keypresses are recognized. On Tue, Jan 14, 2014 at 12:21 PM, Wes Sisk (wsisk) <ws...@cisco.com<mailto:ws...@cisco.com>> wrote: What is the case number? I'm not saying the answer is "right" yet. I will say that DTMF capabilities are part of caps exchange and can cause capability mismatch, extra media resource requests, possible resource exhaustion, and call failure. -Wes ________________________________ From: cisco-voip [cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>] on behalf of Matthew Loraditch [mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>] Sent: Friday, January 10, 2014 5:40 PM To: Matthew Loraditch; Erick Wellnitz Cc: cisco-voip voyp list Subject: Re: [cisco-voip] SNR/Mobility Not Working for Transferred Calls with User Control Well I just had a fun 45 minute geek out with an Escalation Engineer who while we had a good discussion is extremely reluctant to file a defect and wants to point me to the customer's account team and a feature request before he files a bug. The engineer was trying to say that this Note- my emphasis in bold (from here http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/mobilapp.html) The user control mobile voicemail avoidance method is completely dependent on successful relay of the DTMF tone from the remote destination on the mobile voice network or PSTN all the way to Unified CM. The DTMF tone must be sent out-of-band to Unified CM. If DTMF relay is not properly configured on the network and system, DTMF will not be received and all call legs to remote destinations relying on the user control method will be disconnected. The system administrator should ensure proper DTMF interoperation and relay across the enterprise telephony network prior to enabling the user control method. If DTMF cannot be effectively relayed from the PSTN to Unified CM, then the timer control mobile voicemail avoidance method should be used instead. Is indicating that I am having a DTMF relay issue causing the calls to not connect to the remote destination. That is course not the case because then the calls direct to the extensions wouldn't ring the remote destination either. He also couldn't point me to any log file entry indicating as such. Anyway apparently I'm off to figure out this customer's account team for this FY and try to have them file a request... Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518<tel:443.541.1518> fax. 410.252.9284<tel:410.252.9284> Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830<tel:410.252.8830> From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>] On Behalf Of Matthew Loraditch Sent: Wednesday, January 08, 2014 5:09 PM To: Erick Wellnitz Cc: cisco-voip voyp list Subject: Re: [cisco-voip] SNR/Mobility Not Working for Transferred Calls with User Control Well it seems at least we are all in agreement that the engineer we got on this case is off his rocker a bit. We are still pushing him. Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518<tel:443.541.1518> fax. 410.252.9284<tel:410.252.9284> Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830<tel:410.252.8830> From: Erick Wellnitz [mailto:ewellnitzv...@gmail.com] Sent: Wednesday, January 08, 2014 1:37 PM To: Matthew Loraditch Cc: Ryan Ratliff (rratliff); cisco-voip voyp list Subject: Re: [cisco-voip] SNR/Mobility Not Working for Transferred Calls with User Control Works as expected for me on 9.1.2 with H323 gateways and PRIs. On Tue, Jan 7, 2014 at 7:37 PM, Matthew Loraditch <mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>> wrote: I should say it also works if just the extension is dialed on an internal to internal call. Sent from my iPad On Jan 7, 2014, at 8:29 PM, "Matthew Loraditch" <mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>> wrote: Remote destination doesn't ring when the call is transferred to the user. Receptionist is best example. (Not a CUxAC user just regular phone) If the users DID is called remote destination rings. Sent from my iPad On Jan 7, 2014, at 8:23 PM, "Ryan Ratliff (rratliff)" <rratl...@cisco.com<mailto:rratl...@cisco.com>> wrote: Can you be more specific in what doesn't work? The user control option for SNR calls wouldn't be there if it flat out didn't work. As you noted it does require DTMF to get back to CUCM before the call will be cut through to the mobile but that should be it. -Ryan On Jan 7, 2014, at 11:48 AM, Matthew Loraditch <mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>> wrote: We are being told by TAC this doesn't work. The customer thinks it should and I frankly agree. We are insisting they provide documentation to prove the behavior is not a bug. They have referenced the SRND but I am not reading anything where it says SNR only works with Timer Control. In fact the user control section doesn't list any caveats except that DTMF relay must be working. Anyone have any insight here? If it's a bug that's fine but there should be a bug ID. <image001.jpg> Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518<tel:443.541.1518> fax. 410.252.9284<tel:410.252.9284> Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830<tel:410.252.8830> <image002.png> _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
