Transfer issues with version 1.4

Hello All,

I have recently upgraded my system from 1.0.9 to 1.4, my handsets are all polycom 501s. I am using the park and queue features of the system. In 1.0.9, my receptionist would answer the call, press transfer, dial 700, wait to hear 701 or 702… then press transfer again.

Now that I have upgraded, this no longer works. I have also found that transfers to our support queue no longer works either. Here is what happends; Receptionist answers the call, presses 700 (or 800 the support queue), then hears the parking spot or queue transfer notice, and when the receptionist presses the transfer key again, the key is dead, it does not do anything.

Here is what I have noticed; the second time the receptionist presses transfer, the music on hold player stops. I have also noticed, that if I perform a blind transfer the transfers work to both the parking lot and the support queue. The only problem with a blind transfer is that the receptionist has no idea what parking slot the call is in since a blind transfer does not announce the slot.

The second issue I have, is the change made to the music on hold player. The fact that the player starts and stops all the time in my opinion sucks! I also don’t like that it spawns a new player session for each person on hold. Is there any way to configure the new player like the old one, more of a streaming player that the holding callers attach to?

Thanks,
Greg

I seem to have the exact same problem. Has someone found a solution to this???

Since no-one is offering any feedback, you may have discovered a bug in a feature that is not widely used. Might be worth checking

http://bugs.digium.com/main_page.php

to see if any of your keywords are mentioned. I did check in 1.4 for ‘transfer’ and there are no records. However, I have found the guys there to be both attentive to problems and pretty quick on providing corrections.

Hi,

I did some more debugging with verbose at 10 and sip debug on and found the problem. I don’t think this is a bug. However this seems to be new behaviour of asterisk:

Failed SIP Transfer to non-existing extension 1234567 in context default

I am trying to transfer to an outside extension that I would not have in the default context. However the transfer will only work to extensions that are in the default context. So somewhere there’s been a change that you can’t transfer to any extension the sip channel is allowed to use but only to extensions in the default context. Now I came accross transfercontext somewhere on the internet but have not yet found the right place to define this.

I hope I’m making sense here…

I’ll post an update if I find something but in the meantime would also appreciate any comments anyone here might have.

ciao,

Cybertoy

Asterisk often assumes the default context when it has not been told otherwise (for example voicemail), or it cannot make sense of the instruction to use the specific context. Have you checked your syntax to make sure the proper context is specified?

it’s been a while but I figure I’ll answer my own question:

  • There’s a global channel variable called TRANSFER_CONTEXT that defines the context you can use when transferring. It seems like that defaults to “default”.

  • You can either define this variable in the [globals] secion of your extensions.conf …

  • … or you can define it per channel. If you define it per channel make sure you use the two underscores so that upon handing off into a new channel the new definition sticks.

… see also the doc/channelvariables.txt file in the source.

ciao,

Cyberoty

This did appear to be a bug in an early version of 1.4. Now that I have upgraded to 1.4.10 the problem has disappeared.