No hold music during attended transfers.

[sssputnik]

Caller calls in, speaks to reception, reception does attended transfer to Bob.
Whilst transfer is happening and reception is telling Bob he has a call, the caller gets dead silence on the line till Bob starts speaking.

Latest v9
Yealink phones

Any ideas? Suggestions?

 

[sssputnik]

In addition to that, if I put a call on hold I get no hold music either. Probably related.

This is a new build on v9, different network setup to my last box...

Any troubleshooting steps etc appreciated.

 

[captivateglobal]

From what I can tell there's no way to debug or interface with the MoH, but, I'd take a random guess and say that the 'onhold.mp3' file has been deleted?

Just double check over all of your settings in the 'General' tab, there is five music on hold file spots, and you can change the way they work with checkboxes. Failing that there's no way to troubleshoot it that I can see.

Also some phones might attempt to reinvite the caller to nowhere when they transfer; if you disable reinvites on 3CX that would stop that issue.

 

[sssputnik]

The MP3 file appears to be in the store.

To eliminate this, I copied a copy over to a new folder and told 3CX to use that, no dice.

I have turned off Reinvite on the VoIP trunk, the reception handset and the end target destination handset and still no good.

Stuck... Help!

 

[sssputnik]

Could this be a network problem?

I say this, as the 3CX system has two NICs. One for LAN (Handsets) and one for SIP trunk, (public IP internet).
(We have a dedicated fibre optic SIP trunk).

Could hold music engine or whatever be bound to wrong NIC or something?

 

[captivateglobal]

Could this be a network problem?

I say this, as the 3CX system has two NICs. One for LAN (Handsets) and one for SIP trunk, (public IP internet).
(We have a dedicated fibre optic SIP trunk).

Could hold music engine or whatever be bound to wrong NIC or something?

What you can do is get Wireshark captures for the SIP packets on either interface of the 3CX machine, and inspect the RTP addresses exchanged during being placed on hold. Then have a look at the resulting RTP.

3CX should tell the client it's being reinvited to 3CX's public IP. The client should send an address to 3CX for it to send MoH audio to - if the address is correct, and 3CX responds 200 OK, then the 3CX server will start sending RTP to this destination.

You should be able to see at that point some RTP traffic will start on either one of the interfaces, and you'll be able to see which NIC 3CX is sending from.

 

[sssputnik]

Thanks, will have a look!

 

[sssputnik]

The problem was the MP3 file we were using. Unsure why.
The file worked in Version 8 OK.

I tested the file to ensure it played in WMP. Is OK. Copied to the 3CX system, no good.

Chose a different WAV file on 3CX as a test, and it worked.

Converted the MP3 to WAV and it then worked also.

Puzzled, perhaps a weird format MP3 or something?
I should note, that apart from 3CX being changed from v8 to v9 we also changed OS from Win2K3 32 bit to 2008R2.

 

[LeonidasG_3CX]

As we do supported other sound file formats, the best one to use with 3CX is always a wav file.
During the next release we plan to give some ephasis on this in some areas of the phonesystem.