Music On Hold (Inbound Routes) problem

Distro Discussion & Help
1

Hi,

Excellent distro - really impressed with the way this setup.

Only problem I have encountered is do do with MOH - and I am not sure if this is a FreePBX issue or Asterisk. All I know is that it works ok on our existing PIAF 1.4 CentOS 5.2 systems.

When you configure the trunk to terminate a call using MOH ‘forever’ it plays the MOH setting as configured on the Inbound Routes page ok but the call is terminated after 30 seconds. Can this setting be changed and if so, where? For testing purposes it is fine to be able to not terminate the call but leave it on hold as described i.e. forever

The other MOH setting is when you set the Inbound Route to call an extension - the MOH that is played when the extension places the call on hold is NOT the MOH selection that is shown on the Inbound Route page - it plays the default MOH instead. On PIAF and FreePBX 2.6 the extension uses the MOH as selected in the Inbound Route config.

Excuse me if I have missed a thread on this but I checked the forum but did not see anyone report this particular MOH issue.

Many thanks,

Andy

2

Tony/Philippe,

Just building another system on a public IP just in case you need to look at it remotely.

It is SIP trunks we are using for testing but the same SIP trunk on PIAF and Asterisk 1.4 plays out MOH ‘forever’ but the same trunk transferred to FreePBX distro terminates exactly at 30 seconds so don’t think it is provider related.

The main issue is the fact that the Extension placing a called on hold get the default MOH and NOT the one configured on the trunk - are you able to test that. I have the SIP line Inbound Route setup for a custom category and the line pointing at Extension XXX - when the extension places the caller on hold the music that is played is NOT the custom category that is selected in the Inbound Route settings.

This is a DEV server so we can do anything with it - just getting confidence in the system to allow us to put it into production and retire the old 1.4’s

Thanks so much for such a prompt response.

Andy

3

Thanks very much - glad you found it.

Best wishes,

Andy

4

ajsteven,

what I need to see is the call coming into the system and traversing the dialplan. What you provided confirms that it is playing the default category so that is not in question.

But by seeing the call go through the dialplan up until being answered will let me see if we are doing what we are suppose to be doing or not.

5

and in fact this is probably the bug right here, got no idea where it came from:

exten => s,n,ExecIf($["${MOHCLASS}"!=""]?Set(CHANNEL(musicclass)=${MEETME_MUSIC}))

shoudl be MOHCLASS, not MEETME_MUSIC…

6

#5109 filed, you can pull the patch and test to see if it fixes things, it was definitely broken :frowning:

will get it published soon, just want to check if there are any other outstanding things that need to be checked into core before pushing it out.

7

ajsteven,

I understand with the ‘none’ category you are still getting the default MoH played. If you define another category do you have the same issue?

The ‘none’ category has had problems in the past so I could imagine there could be an issue with that and thus would like to know the answer to the above.

If you are still running into that, can you provide a CLI trace of the inbound call hitting the system and then getting placed on hold? That may be helfpful to see what is going on.

8

Philippe,

Yes selecting either NONE or a NEW CATEGORY on the INBOUND ROUTE page still plays the DEFAULT MOH when the extension places the line on hold.

Here is the relevant extract from the CLI - let me know if you need any more detail.

Both tests were done either selecting NONE or TEST (the new category).

If I terminate the inbound route to MOH - it plays the selected MOH ok - it appears to be related to the Extension placing caller on hold where it ignores the setting.

Andy

WITH MOH=NONE

– Executing [s@macro-dial-one:42] Dial(“SIP/sipgate70xxxx-00000002”, “SIP/1000,”",trI") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Called 1000
– SIP/1000-00000003 is ringing
– SIP/1000-00000003 is ringing
– Connected line update to SIP/sipgate70xxxx-00000002 prevented.
– SIP/1000-00000003 answered SIP/sipgate70xxxx-00000002
– Started music on hold, class ‘default’, on SIP/sipgate70xxxx-00000002
– Stopped music on hold on SIP/sipgate70xxxx-00000002
– Executing [h@macro-dial-one:1] Macro(“SIP/sipgate70xxxx-00000002”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“SIP/sipgate70xxxx-00000002”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] Hangup(“SIP/sipgate70xxxx-00000002”, “”) in new stack

WITH MOH=TEST

== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Called 1000
– SIP/1000-00000005 is ringing
– Connected line update to SIP/sipgate70xxxx-00000004 prevented.
– SIP/1000-00000005 answered SIP/sipgate70xxxx-00000004
– Started music on hold, class ‘default’, on SIP/sipgate70xxx-00000004
– Stopped music on hold on SIP/sipgate70xxxx-00000004

WITH LINE TERMINATED to MOH - correct MOH plays

– Goto (app-blackhole,musiconhold,1)
– Executing [musiconhold@app-blackhole:1] NoOp(“SIP/sipgate70xxxx-00000006”, “Blackhole Dest: Put caller on hold forever”) in new stack
– Executing [musiconhold@app-blackhole:2] Answer(“SIP/sipgate70xxxx-00000006”, “”) in new stack
– Executing [musiconhold@app-blackhole:3] MusicOnHold(“SIP/sipgate70xxxx-00000006”, “”) in new stack
– Started music on hold, class ‘Test’, on SIP/sipgate70xxxx-00000006
[2011-04-26 23:44:48] NOTICE[15006]: channel.c:4046 __ast_read: Dropping incompatible voice frame on SIP/sipgate70xxxx-00000006 of format ulaw since our native format has changed to 0x8 (alaw)
– Stopped music on hold on SIP/sipgate70xxxx-00000006
== Spawn extension (app-blackhole, musiconhold, 3) exited non-zero on ‘SIP/sipgate70xxxx-00000006’

9

Tony/Philippe,

New build does not have the 30sec timeout on MOH - this appears to be caused with a SIP line and a NAT issue. When on public IP this ‘problem’ has gone.

However, the MOH settings for the music played when the Extension puts a caller on hold is still troublesome. Even setting the MOH on the Inbound Route to NONE it still plays the default MOH when the caller is put on hold.

Am I missing the obvious here…is the extension MOH set elsewhere? I assumed the MOH was related to the inbound route when the extension placed the caller on hold??

Andy

10

Can you open a bug in FreePBX trac for this so we can take a look. It seems to be a 2.9 bug that has not been reported yet from what I can find.

11

Just tested it with no problems. Made it 4 minutes before I hung up.

Are you using SIP trunks? If so my guess without seeing log traces is the MoH is being played as early media and the channel is never answered so eventually your carrier terminates the call.

12

if it’s an issue, it’s more likely either a 2.9 issue or somehow Asterisk related.

Someone will have to do some tests on one of our development Distro systems to see if we are seeing the same thing or not.

btw - thanks for the compliments on the Distro, Tony and his team put a lot into it trying to maximize the experience, quality, etc…

13

I’ve been arround this for a while.

My moh only works on internal calls

[2013-10-25 22:05:17] VERBOSE[14917][C-000000e1] res_musiconhold.c: – Started music on hold, class ‘SinalChamar’, on SIP/G9 244xxxxx-000001a1

Asterisk 11.2-cert2, Copyright © 1999 - 2012 Digium, Inc. and others.
FreePBX 2.11.0.11
CentOS release 6.4 (Final)
2.6.18-194.32.1.el5

It doesn’t seem to be a config issue, it has worked before…

I’ve read somewhere that it is nat related, but I think I have all the necessary ports redirected:
UDP 2727
UDP 5004-2082
UDP 10000-20000

Any ideas???

Thanks in advance for your help.

Cya…

14

On my last post there was an error about my system:
CentOS release 5.5 (Final)
2.6.18-194.32.1.el5 x86_64 GNU/Linux

15

I changed the asterisk version to 11.6.0 and the problem seems to be solved, don’t know why…