No audio with ring groups

Asterisk Asterisk Dialplan
1

I just noticed today that ring groups don’t seem to pass audio without answer supervision:

exten => 4444,1,Dial(Local/s@test1&Local/s@test2)
	same => n,Hangup()

[test1]
exten => s,1,Progress()
	same => n,MusicOnHold(ringback)
	same => n,Wait(60)
	same => n,Hangup()

[test2]
exten => s,1,Wait(60)
	same => n,Hangup()

The only way to hear audio is to change test1,s,1 to Answer() instead of Progress().

However, this is contrary to the behavior if only a single peer is dialed. For example, if I do this, I do hear audio:

exten => 4444,1,Dial(Local/s@test1)
	same => n,Hangup()

[test1]
exten => s,1,Progress()
	same => n,MusicOnHold(ringback)
	same => n,Wait(60)
	same => n,Hangup()

Is this intentional - for Asterisk to not pass audio with ring groups unless something supervises? (Once something supes, audio passes fine). I’d been assuming dialing multiple peers would behave the same way as single peer dials, but this seems not to be the case. Is this intentional? If so, is there any way to pass audio through from a particular endpoint without supervising?

2

It’s intentional, because it would have to arbitrarily select one outgoing channel as a source of audio.

In the original implementation, there is no bridge; Dial is forwarding the media itself. there may now be an early media bridge, but I doubt there is an early media conference bridge.

3

Hmm… I can see why that makes sense!

Is there any way to make it pass audio from the first channel that provides Progress()? In fact, that’s originally what I was trying to do. I have a Progress() in the primary channel dialed and no Progress() in the secondary channels, with the goal of passing audio from the first channel.

4

The app_dial module would have to have support for such a thing added.

5

I think what you need is the m option of Dial()

m([class]): Provide hold music to the calling party until a requested

channel answers. A specific music on hold (as defined in
“musiconhold.conf”) can be specified.

I think with m you don’t need to use progress() any more.

6

That is, in fact, what I am doing now, because it seems there is no other option.

However, I’m a bit uncomfortable as this is generating “fake ringback tone” instead of passing the real ringback tone through from at least one of the endpoints.

As a compromise, on such calls that dial multiple peers, I set a channel variable, and if a line is busy (and no Call Forwarding Busy active, etc.), instead of playing busy tone, I hang up with the Busy Hangup Cause code. Thus, if everything happened to be busy, I can now capture that and play busy tone for the whole ring group. But otherwise, it’s possible one might continue to hear audible ring forever even if nothing is actually ringing.

Imperfect, but this seems like the best I can do.