Author Topic: Unable to transfer from hold  (Read 2871 times)

Offline scottyg

  • Contributer
  • *
  • Posts: 5
  • Country: us
  • Karma: +0/-0
    • View Profile
Unable to transfer from hold
« on: February 05, 2015, 01:35:39 PM »
Mitel 5000 w/ remote 8662e phones.  No MBG  involved on the remote end.  Cable modem bridge -> Linksys WRT54GL w/ Tomato.

User on the remote end cannot pick up calls that have been placed on hold by someone else.  He sees a solid red light, not a blinking one, that would indicate he can pick up.

This is actually happening on a couple remote sites now.
Any idea what could be happening?
All other remote sites are working fine.
We are using 1:1 Nat on PBX on main office, and I know people have reported problems with this, but I would think that the fact that some remote sites work fine, would indicate that the 1:1 NAT isn't the culprit.
Anyway, anyone have any ideas?  I'm stumped and a bit frustrated, after spending the last week and a half replacing the remote user's Comcast Netgear modem/firewall with a Motorola SB6141, and configuring the Tomato gateway, thinking that Comcast's equipment was causing the issue.
Still happening though.
Thanks for any ideas!


Offline Tech Electronics

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2983
  • Country: us
  • Karma: +89/-1
    • View Profile
Re: Unable to transfer from hold
« Reply #1 on: February 05, 2015, 09:00:46 PM »
Scottyg,

If you have verified that other remote phones on that same system are able to Reverse Transfer a call then have you copied over the network settings of those phones so you know they are the same?

Have you brought an 8662 up locally and copied the settings from one of the phones that is not able to Reverse Transfer and verified whether or not it is able to do it?

Thanks,

TE

Offline scottyg

  • Contributer
  • *
  • Posts: 5
  • Country: us
  • Karma: +0/-0
    • View Profile
Re: Unable to transfer from hold
« Reply #2 on: February 06, 2015, 12:49:28 PM »
Thanks for the reply.  I have verified that the PBX-side config for both good and bad extension is the same, and have also verified that the config in each phone is the same when placed into programming mode.

Is there any other config I should be aware of?

I ended up finally opening a support ticket with Mitel Support, though from past experience, I'm not sure they will be at all helpful.
I'll update this thread with results as they come.  In the meantime, if any other ideas pop into mind, do let me know.
Thanks!

Offline Tech Electronics

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2983
  • Country: us
  • Karma: +89/-1
    • View Profile
Re: Unable to transfer from hold
« Reply #3 on: February 06, 2015, 01:15:19 PM »
Scottyg,

What does it show when the user tries to perform a Reverse Transfer from a phone that you know has a call on hold?

Thanks,

TE

Offline DND ON

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 908
  • Country: us
  • Karma: +23/-0
    • View Profile
Re: Unable to transfer from hold
« Reply #4 on: February 06, 2015, 05:00:52 PM »
You said that the lamp is solid red, not blinking. Is this a trunk key? If so, is the remote phone included in the list for Answer Access on that trunk group?

Offline 619Tech

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 230
  • Country: us
  • Karma: +1/-0
    • View Profile
Re: Unable to transfer from hold
« Reply #5 on: February 09, 2015, 12:00:35 PM »
scottyg - If you can call between endpoints, and have two way audio, your NAT/NTWK settings are fine. This is probably a feature implementaion or execution error. Are the endpoints involved using system hold or individual hold? Call keys or Individual Trunk keys? The solid RED light is what kind of key?

Offline scottyg

  • Contributer
  • *
  • Posts: 5
  • Country: us
  • Karma: +0/-0
    • View Profile
Re: Unable to transfer from hold
« Reply #6 on: February 19, 2015, 02:28:43 PM »
Just wanted to post a follow-up here in case it helps the next person.

Problem was that the user who could not pick up calls placed on hold, was not a member of the Trunk Group that placed the call on hold.
Specifically, that user's keymap was pointed to the wrong Hunt Group.

cheers


 

Sitemap 1 2 3 4 5 6 7 8 9 10