Trying to disable MOH (with a barge)

[EXviciman]

Hello Vicidial fellows,

My Machine:

Asterisk 11.25.3-vici built by abuild @ lamb68 on a x86_64 running Linux on
ViciBox v.8.0.1
VERSION: 2.14-675a
BUILD: 180520-1749

My Issue:

We use a sip phone that you can fast move between calls in so you can fastly barge/whisper/monitor

It all works fine , BUT when you barge then put a call on hold via the barge it plays this Music on Hold and I am trying to take it off... At least even for certain phones/extensions

What I tried:

Searched a ton about the MusicOnHold config files.

Also saw that I could mute the barging guy via the asterisk cli so the guys there don't hear the music. Though this seems like too much of a manual solution that I don't think is easy to implement.
I am quite sure there must be a better way.

So how would you recommend to get rid of this music on hold (and yes I saw that this is the asterisk playing it!!! says on cli)

please advise.

Thanks,
EXviciman

[williamconley]

We need the path of the call and how it happens to have MOH. Of course asterisk is playing it, since asterisk is the PBX, but asterisk isn't initiating it necessarily. There is likely a script initiating the MOH and then turning it off when appropriate.

So the full path of the call to land in whatever situation it's in is necessary to decide how to kill the MOH (and/or turn it back on when you jump to the next channel).

Another concept is WHY we need to turn off MOH? Barging isn't usually something one does for a call on hold, usually one would barge on a conference room with an agent talking to a lead, and of course that would not have MOH in the first place. Seems likely you are trying to reinvent a wheel and "do it your way" instead of just using a function that has already been written into Vicidial to accomplish the same task (ie: all this has already been "handled" in an existing feature).

[EXviciman]

Not sure what you mean by the path of the call.... Asterisk cli output would work here? (You can give an example)

Well what happens is that a Manager connects to two calls at the same time for the same conference:
One via BB (Barge)
Two via BW (Whisper)
So then he switches between them with a one click (We do that also we blind monitor - the managers /QA guys find it convenient).

The issue is when you switch from barge to whisper/monitor. The asterisk picks up you put the call on hold and plays Music On Hold <-------------------This is what I would like to prevent

[EXviciman]

- Executing [192*168*020*200*8600051@default:1] Goto("Local/192*168*020*200*8600051@default-00000067;2", "default,8600051,1") in new stack
[Jul 24 19:30:15] -- Goto (default,8600051,1)
[Jul 24 19:30:15] -- Executing [8600051@default:1] MeetMe("Local/192*168*020*200*8600051@default-00000067;2", "8600051,F") in new stack
[Jul 24 19:30:15] > Channel Local/192*168*020*200*8600051@default-00000067;1 was answered
[Jul 24 19:30:15] -- Executing [999@default:1] Dial("Local/192*168*020*200*8600051@default-00000067;1", "SIP/999,60,") in new stack
[Jul 24 19:30:15] == Using SIP RTP CoS mark 5
[Jul 24 19:30:15] -- Called SIP/999
[Jul 24 19:30:15] > 0x7fc508016d60 -- Strict RTP learning after remote address set to: 192.168.20.2:36380
[Jul 24 19:30:15] -- SIP/999-00000065 answered Local/192*168*020*200*8600051@default-00000067;1
[Jul 24 19:30:15] > 0x7fc508016d60 -- Strict RTP switching to RTP remote address 192.168.20.2:36380 as source
[Jul 24 19:30:16] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:30:17] > 0x7fc508016d60 -- Strict RTP learning complete - Locking on source address 192.168.20.2:36380

This is the cli output of the barge basically

[williamconley]

The calls to which you are "attaching". I get the implication that each of the calls is in a meetme room (ie: lead and agent in conference), but I've not seen that yet either in a description or asterisk cli. The "barge" was informative, though, in that it at least implies the meetme conference is involved. I did not see a "MOH" entry in the example provided.

Based on what I've seen so far: the phone is sending a "HOLD" instruction to asterisk when the PHONE puts each call on hold.

1) stop putting the call on hold. just disconnect from it. (and reconnect silently when you come back)

2) change the MOH context to one that has no music.

3) See if the phone has any adjustments for this behavior that may apply.

[EXviciman]

This was just an empty barge on a none live call - just to see I understood what you were talking about sec will supply some more detailed example

[EXviciman]

[Jul 24 19:52:25] -- Executing [8600051@default:1] MeetMe("Local/8600051@default-00000069;2", "8600051,F") in new stack
[Jul 24 19:52:25] > Channel Local/8600051@default-00000069;1 was answered
[Jul 24 19:52:25] -- Executing [66614146539870@default:1] AGI("Local/8600051@default-00000069;1", "agi://127.0.0.1:4577/call_log") in new stack
[Jul 24 19:52:25] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=CAMP1))
[Jul 24 19:52:25] -- <Local/8600051@default-00000069;1>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jul 24 19:52:25] -- Executing [66614146539870@default:2] Dial("Local/8600051@default-00000069;1", "SIP/donaldtrunk/66614146539870,,tTo") in new stack
[Jul 24 19:52:25] == Using SIP RTP CoS mark 5
[Jul 24 19:52:25] -- Called SIP/donaldtrunk/66614146539870
[Jul 24 19:52:26] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:52:26] > 0x7fc4f0006f80 -- Strict RTP learning after remote address set to: 172.217.169.69:25842
[Jul 24 19:52:26] -- SIP/donaldtrunk-00000067 is making progress passing it to Local/8600051@default-00000069;1
[Jul 24 19:52:26] > 0x7fc4f0006f80 -- Strict RTP switching to RTP remote address 172.217.169.69:25842 as source
[Jul 24 19:52:26] == Manager 'sendcron' logged on from 127.0.0.1
[Jul 24 19:52:26] -- Executing [58600051@default:1] MeetMe("Local/58600051@default-0000006a;2", "8600051,Fmq") in new stack
[Jul 24 19:52:26] > Channel Local/58600051@default-0000006a;1 was answered
[Jul 24 19:52:26] -- Executing [8309@default:1] Answer("Local/58600051@default-0000006a;1", "") in new stack
[Jul 24 19:52:26] -- Executing [8309@default:2] Monitor("Local/58600051@default-0000006a;1", "wav,20190725-025224_14146539870") in new stack
[Jul 24 19:52:26] -- Executing [8309@default:3] Wait("Local/58600051@default-0000006a;1", "3600") in new stack
[Jul 24 19:52:27] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:52:28] > 0x7fc4f0006f80 -- Strict RTP learning complete - Locking on source address 172.217.169.69:25842
[Jul 24 19:52:30] -- SIP/donaldtrunk-00000067 answered Local/8600051@default-00000069;1
[Jul 24 19:52:36] == Manager 'sendcron' logged on from 127.0.0.1
[Jul 24 19:52:36] -- Executing [192*168*020*200*473782188600051@default:1] Goto("Local/192*168*020*200*473782188600051@default-0000006b;2", "default,473782188600051,1") in new stack
[Jul 24 19:52:36] -- Goto (default,473782188600051,1)
[Jul 24 19:52:36] -- Executing [473782188600051@default:1] Answer("Local/192*168*020*200*473782188600051@default-0000006b;2", "") in new stack
[Jul 24 19:52:36] > Channel Local/192*168*020*200*473782188600051@default-0000006b;1 was answered
[Jul 24 19:52:36] -- Executing [999@default:1] Dial("Local/192*168*020*200*473782188600051@default-0000006b;1", "SIP/999,60,") in new stack
[Jul 24 19:52:36] == Using SIP RTP CoS mark 5
[Jul 24 19:52:36] -- Called SIP/999
[Jul 24 19:52:36] > 0x7fc50803fd40 -- Strict RTP learning after remote address set to: 192.168.20.2:37146
[Jul 24 19:52:36] -- SIP/999-00000068 answered Local/192*168*020*200*473782188600051@default-0000006b;1
[Jul 24 19:52:36] > 0x7fc50803fd40 -- Strict RTP switching to RTP remote address 192.168.20.2:37146 as source
[Jul 24 19:52:36] -- Executing [473782188600051@default:2] Wait("Local/192*168*020*200*473782188600051@default-0000006b;2", "1") in new stack
[Jul 24 19:52:37] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:52:37] -- Executing [473782188600051@default:3] AGI("Local/192*168*020*200*473782188600051@default-0000006b;2", "getAGENTchannel.agi") in new stack
[Jul 24 19:52:37] -- Launched AGI Script /usr/share/asterisk/agi-bin/getAGENTchannel.agi
[Jul 24 19:52:37] -- <Local/192*168*020*200*473782188600051@default-0000006b;2>AGI Script getAGENTchannel.agi completed, returning 0
[Jul 24 19:52:37] -- Executing [473782188600051@default:4] NoOp("Local/192*168*020*200*473782188600051@default-0000006b;2", "SIP/990-00000066") in new stack
[Jul 24 19:52:37] -- Executing [473782188600051@default:5] GotoIf("Local/192*168*020*200*473782188600051@default-0000006b;2", "0?fin") in new stack
[Jul 24 19:52:37] -- Executing [473782188600051@default:6] ChanSpy("Local/192*168*020*200*473782188600051@default-0000006b;2", "SIP/990-00000066,qw") in new stack
[Jul 24 19:52:37] == Spying on channel SIP/990-00000066
[Jul 24 19:52:37] NOTICE[4926][C-000000c8]: app_chanspy.c:491 start_spying: Attaching Local/192*168*020*200*473782188600051@default-0000006b;2 to SIP/990-00000066
[Jul 24 19:52:37] NOTICE[4926][C-000000c8]: app_chanspy.c:491 start_spying: Attaching Local/192*168*020*200*473782188600051@default-0000006b;2 to SIP/990-00000066
[Jul 24 19:52:37] > 0x7fc50803fd40 -- Strict RTP learning complete - Locking on source address 192.168.20.2:37146
[Jul 24 19:52:44] == Manager 'sendcron' logged on from 127.0.0.1
[Jul 24 19:52:44] -- Executing [192*168*020*200*8600051@default:1] Goto("Local/192*168*020*200*8600051@default-0000006c;2", "default,8600051,1") in new stack
[Jul 24 19:52:44] -- Goto (default,8600051,1)
[Jul 24 19:52:44] -- Executing [8600051@default:1] MeetMe("Local/192*168*020*200*8600051@default-0000006c;2", "8600051,F") in new stack
[Jul 24 19:52:44] > Channel Local/192*168*020*200*8600051@default-0000006c;1 was answered
[Jul 24 19:52:44] -- Executing [999@default:1] Dial("Local/192*168*020*200*8600051@default-0000006c;1", "SIP/999,60,") in new stack
[Jul 24 19:52:44] == Using SIP RTP CoS mark 5
[Jul 24 19:52:44] -- Called SIP/999
[Jul 24 19:52:44] > 0x7fc4b80224e0 -- Strict RTP learning after remote address set to: 192.168.20.2:37148
[Jul 24 19:52:44] -- SIP/999-00000069 answered Local/192*168*020*200*8600051@default-0000006c;1
[Jul 24 19:52:44] > 0x7fc4b80224e0 -- Strict RTP switching to RTP remote address 192.168.20.2:37148 as source
[Jul 24 19:52:44] > 0x7fc50803fd40 -- Strict RTP learning after remote address set to: 192.168.20.2:37150
[Jul 24 19:52:44] -- Started music on hold, class 'default', on Local/192*168*020*200*473782188600051@default-0000006b;1
[Jul 24 19:52:44] > 0x7fc50803fd40 -- Strict RTP switching source address to 192.168.20.2:16776
[Jul 24 19:52:45] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:52:45] > 0x7fc4b80224e0 -- Strict RTP learning complete - Locking on source address 192.168.20.2:37148
[Jul 24 19:52:45] > 0x7fc50803fd40 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16776
[Jul 24 19:52:54] > 0x7fc4b80224e0 -- Strict RTP learning after remote address set to: 192.168.20.2:37158
[Jul 24 19:52:54] -- Started music on hold, class 'default', on Local/192*168*020*200*8600051@default-0000006c;1
[Jul 24 19:52:54] > 0x7fc50803fd40 -- Strict RTP learning after remote address set to: 192.168.20.2:37150
[Jul 24 19:52:54] -- Stopped music on hold on Local/192*168*020*200*473782188600051@default-0000006b;1
[Jul 24 19:52:54] > 0x7fc4b80224e0 -- Strict RTP switching source address to 192.168.20.2:16779
[Jul 24 19:52:55] > 0x7fc4b80224e0 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16779
[Jul 24 19:52:55] > 0x7fc50803fd40 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16776
[Jul 24 19:53:00] > 0x7fc50803fd40 -- Strict RTP learning after remote address set to: 192.168.20.2:37150
[Jul 24 19:53:00] -- Started music on hold, class 'default', on Local/192*168*020*200*473782188600051@default-0000006b;1
[Jul 24 19:53:00] > 0x7fc4b80224e0 -- Strict RTP learning after remote address set to: 192.168.20.2:37158
[Jul 24 19:53:00] -- Stopped music on hold on Local/192*168*020*200*8600051@default-0000006c;1
[Jul 24 19:53:00] -- Stopped music on hold on Local/192*168*020*200*473782188600051@default-0000006b;1
[Jul 24 19:53:02] > 0x7fc50803fd40 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16776
[Jul 24 19:53:02] > 0x7fc4b80224e0 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16779
[Jul 24 19:53:02] == Manager 'sendcron' logged on from 127.0.0.1
[Jul 24 19:53:03] == Manager 'sendcron' logged on from 127.0.0.1
[Jul 24 19:53:03] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:53:03] == Manager 'sendcron' logged off from 127.0.0.1
[Jul 24 19:53:04] > 0x7fc4b80224e0 -- Strict RTP learning after remote address set to: 192.168.20.2:37158
[Jul 24 19:53:04] > 0x7fc50803fd40 -- Strict RTP learning after remote address set to: 192.168.20.2:37150
[Jul 24 19:53:04] -- Started music on hold, class 'default', on Local/192*168*020*200*8600051@default-0000006c;1
[Jul 24 19:53:04] -- Stopped music on hold on Local/192*168*020*200*8600051@default-0000006c;1
[Jul 24 19:53:06] > 0x7fc4b80224e0 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16779
[Jul 24 19:53:06] > 0x7fc50803fd40 -- Strict RTP learning complete - Locking on source address 192.168.20.2:16776
[Jul 24 19:53:08] == Manager 'sendcron' logged on from 127.0.0.1
[Jul 24 19:53:08] == Manager 'sendcron' logged off from 127.0.0.1


First we make a call,
Then we connect whisper,
Then we connect barge,
Then we go back and forth between barge & whisper.

Note: Interesting enough it seems that only actually on the second time where you switch between barge and whisper you get this MOH. Not sure why.

[EXviciman]

1) stop putting the call on hold. just disconnect from it. (and reconnect silently when you come back)

That's not convenient for the managers / QA people - needs to be 1 click to switch from whisper to barge and vice versa.

2) change the MOH context to one that has no music.

Seems like the way to go if you have a direction about this please write me

3) See if the phone has any adjustments for this behavior that may apply.

That was the first thing I tried really before going into asterisk , it is not from the phone that is asterisk playing this sound regardless what is configured on it (PhonerLite)


If you can advise regarding option number 2 it will be much obliged

[williamconley]

MOH contexts are applied ... based on the pathway of the call. which you haven't provided. lol.

that being said, since your barge/whisper method is not expected to have MOH at all, this may be using the "default" moh.

Try removing all audio OR just putting in a single "silent" entry from the default moh as an experiment.

/vicidial/admin.php?ADD=361111111111&moh_id=default

[EXviciman]

Again not sure what you mean by the pathway of the call... (Sorry for not putting up with the asterisk skills)

I tried to take off all of the audio files from the default context , though then asterisk cli came shouting at me for not having certain files / played some other music instead.

EDIT: currently it has just sip-silence.gsm there ,but there is still music playing

[EXviciman]

Omg I think I realized what I was doing wrong there - not hitting the:

moh reload

in the cli.....

Gosh I hate it when there is that small detail they don't write you anywhere

Thanks william will test on production now as well and will update for the sake of future generations

I would still be happy if you would explain what you meant by PATHWAY OF THE CALL (Like if you could give an example that would be great )

[EXviciman]

Grrrr treacherous production giving me this warning and still platying the music.... :

[Jul 24 20:42:53] WARNING[2945][C-00027d60]: file.c:701 ast_openstream_full: File /var/lib/asterisk/default/0001_conf does not exist in any format
[Jul 24 20:42:53] WARNING[2945][C-00027d60]: res_musiconhold.c:342 ast_moh_files_next: Unable to open file '/var/lib/asterisk/default/0001_conf': No such file or directory

EDIT: restarted asterisk , did a lot of other tests and this finally seems to be ok

[williamconley]

pathway of the call

MOH in vicidial is based on how the call arrived at it's present situation. There are many locations where MOH can be assigned in Vicidial, such as Ingroups. Thus a call waiting in an ingroup for an agent will get MOH based on the MOH chooser for that ingroup. So these calls, in agents meetme rooms, how did they get there? Ingroup? Campaign? DID?

Example: Inbound call from carrier. Routed to trunkinbound. These calls arrive at the DID module, and then can be routed by the DID to a Call Menu. The call menu may route the call through an Ingroup, then to an agent. The agent may transfer to a Transfer Group, and then the call is in a conference with an agent upon arrival. Many of these paths may alter the call's MOH settings, but that's an asterisk function you may need to chase down.

MOH is assigned in some fashion or you wouldn't be able to get it at all. MOH is an asterisk module, of course, but it's configured by Vicidial in ... some ... situations. In theory, any MOH not specified by Vicidial would use the default MOH, though, so if the pathway of the call has no option in Vicidial, that default MOH would do the trick.