MOH for particular extension

Hi there!
Please tell me, can I define MOH for particular peer in sip.conf in peer’s description ?

I want MOH to play for caller when he calls to this peer /extension.
Is it only the way to define this individual extension in extension.conf file and use Dial() with ‘m’ argument to hear MOH when dialing to this extension?
Is it possible to define MOH for that certain SIP peer in sip.conf ?
Thanks!

There is a channel variable that can force the MOH class for the device on the channel on which it is set.

But this variable I have to set in extension configuration in dialplan.conf right?
So I have to define this particular extension in dialplan and set this variable.
It’s the same (in perspective of this task) as to add an option ‘m(class)’ for Dial() Application for this extension. (In Both cases I have to "extract " this extension from configured pattern and assign some options or variable definitely for those extension )

So is there a way to assign a MOH class to the SIP peer exactly in sip.conf and not to be having disorder the dialplan and patterns fo certain extensions?

Look, I have a configured pattern:
exten => _3XXXXX, n, Dial(SIP/${EXTEN})

But for some peer 356789 or some other I want to configure some MOH class.
So I Have to definitely define this extension:
exten => 356789, n, Dial(SIP/${EXTEN},m)
or set the channel variable (as you suggest)
And it “breaks” my pattern especially if such extensions became multiply.

Channel variables can be set in sip.conf.

Ok, this is what I want!
But I cannot find the name of variable that meet which MOH class will be provided to calling party when the call is coming for this channel.
A find only CHANNEL(musicclass) variable but it’s responsible only for MOH class to play WHEN THE CALL PLACED ON HOLD. It’s not a music that calling party listen until a requested channel answers.

So could you please suggest me the name of this magic variable? :smile:
Thanks!

Did you actually try it?

The call IS placed on hold (receives AST_CONTROL_HOLD) when it is waiting in a queue.

Of cause yes!
I tried to define setvar=CHANNEL(musicclass)=some_class
And it’s only affected to MOH provided to calling party when the call is places on hold (manually by pressed a HOLD button on phone).
But the sounds provided to calling party until the call answered remains unchanged.

I’m not sure that Asterisk can ever send music on hold to unanswered calls. I think only Playback supports generating in band progress, assuming the caller’s network allows it.

When you press hold on a phone, the music on hold is sent to the other party, not the holding phone, and therefore depends on the music on hold class configured directly in sip.conf for the holding party (although the channel variable on the held party overrides that).

I’m not sure that Asterisk can ever send music on hold to unanswered calls
Asterisk do this by adding the ‘m’ option to Dial() application .The calling party then listen the MOH until the called aswer the call.
So I trying to find any option or variable for sip peer with the same functionally.

All music on hold eventually goes through ast_moh_start on the channel on which it is going to be played. For Asterisk 1.6.1.0, these are the rules for what gets played:

/* The following is the order of preference for which class to use: * 1) The channels explicitly set musicclass, which should *only* be * set by a call to Set(CHANNEL(musicclass)=whatever) in the dialplan. * 2) The mclass argument. If a channel is calling ast_moh_start() as the * result of receiving a HOLD control frame, this should be the * payload that came with the frame. * 3) The interpclass argument. This would be from the mohinterpret * option from channel drivers. This is the same as the old musicclass * option. * 4) The default class. */

Dial does, in fact, send AST_CONTROL_PROGRESS, which will trigger in band progress if the network allows it, when starting music on hold. However, the PSTN generally doesn’t support in band progress, because it would allow people to offer services without being charged, so will either present ring back instead, or answer the call.

I can’t see any use of AST_CONTROL_PROGRESS in the queue application. We only using ringback on unanswered queue calls, so I’ve had no need to test how MOH behaves if the call is unanswered.

I’m wondering if you are confusing ringback with the default MOH. You might be able to enabel in band progress explicitly, with Progress().

Version 1.6.1.0