[Home]

Summary:ASTERISK-15451: No audio is passed from MOH when using originate to a remote peer
Reporter:Mark Murawski (kobaz)Labels:
Date Opened:2010-01-17 14:18:11.000-0600Date Closed:2011-06-07 14:07:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip
Description:No audio is passed from MOH when using originate to a remote peer

If you issue a Playback(), before MusicOnHold, audio will flow.

---------

extend context services {
 1 => {
   Answer(500);
   MusicOnHold();
 }

 2 => {
   Answer(500);
   Playback(lunch);
   MusicOnHold();
 }
}

5506 is a polycom phone registered on pbx A
on pbx A:
 asterisk -rx "originate SIP/5506 extension 1@services"

   -- Executing [1@services:1] Answer("SIP/5506-00000014", "500") in new stack
   -- Executing [1@services:2] MusicOnHold("SIP/5506-00000014", "") in new stack
   -- Started music on hold, class 'default', on channel 'SIP/5506-00000014'
   -- Remote UNIX connection disconnected
Got  RTP packet from    192.168.5.134:2224 (type 00, seq 034120, ts 3799238534, len 000160)
Sent RTP packet to      192.168.5.134:2224 (type 00, seq 064889, ts 000160, len 000160)
Got  RTP packet from    192.168.5.134:2224 (type 00, seq 034121, ts 3799238694, len 000160)
Sent RTP packet to      192.168.5.134:2224 (type 00, seq 064890, ts 000320, len 000160)
....etc

Everything is fine and dandy.  Here's the problem:

26213 is a polycom phone on demo1 (which is also asterisk).. and this bug exhibits itself whether using sip or iax.

on pbx A
asterisk -rx "originate SIP/demo1-sip/26213 extension 1@services"

   -- Executing [1@services:1] Answer("SIP/demo1-sip-00000015", "500") in new stack
   -- Executing [1@services:2] MusicOnHold("SIP/demo1-sip-00000015", "") in new stack
   -- Started music on hold, class 'default', on channel 'SIP/demo1-sip-00000015'

no RTP!

Now we try a Playback() beforehand.

on pbx A
asterisk -rx "originate SIP/demo1-sip/26213 extension 2@services"

   -- Executing [2@services:1] Answer("SIP/demo1-sip-00000016", "500") in new stack
   -- Executing [2@services:2] Playback("SIP/demo1-sip-00000016", "lunch") in new stack
   -- Remote UNIX connection disconnected
Sent RTP packet to      192.168.15.20:16730 (type 00, seq 049074, ts 000160, len 000160)
   -- <SIP/demo1-sip-00000016> Playing 'lunch.ulaw' (language 'en')
Sent RTP packet to      192.168.15.20:16730 (type 00, seq 049075, ts 000320, len 000160)
Sent RTP packet to      192.168.15.20:16730 (type 00, seq 049076, ts 000480, len 000160)
Sent RTP packet to      192.168.15.20:16730 (type 00, seq 049077, ts 000640, len 000160)
Sent RTP packet to      192.168.15.20:16730 (type 00, seq 049078, ts 000800, len 000160)
....etc
   -- Executing [2@services:3] MusicOnHold("SIP/demo1-sip-00000016", "") in new stack
   -- Started music on hold, class 'default', on channel 'SIP/demo1-sip-00000016'
Got  RTP packet from    192.168.15.20:16730 (type 00, seq 017805, ts 2133860346, len 000160)
Got  RTP packet from    192.168.15.20:16730 (type 00, seq 017806, ts 2133860506, len 000160)
Got  RTP packet from    192.168.15.20:16730 (type 00, seq 017807, ts 2133860666, len 000160)
Sent RTP packet to      192.168.15.20:16730 (type 00, seq 049106, ts 005280, len 000160)
....etc
Comments:By: Mark Murawski (kobaz) 2010-01-17 14:22:27.000-0600

Uploaded sip debug of the problematic call
By: Leif Madsen (lmadsen) 2010-01-18 10:49:22.000-0600

I'm not sure what the resolution will be here -- for your work around, you could also use Playback(silence/1) if you need to trigger something to get the audio flowing first, but don't actually want to play something the caller can hear.
By: Leif Madsen (lmadsen) 2010-01-18 10:50:09.000-0600

Also noting that perhaps the resolution to this issue will be a documentation update about these types of scenarios so people can recognize the situations and causes that requires audio to be generated.
By: Paul Belanger (pabelanger) 2010-06-02 13:56:53

Is this still a problem with 1.6.2? I did not see the same results last week when testing something MOH related.
--
Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch.

More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924

By: Mark Murawski (kobaz) 2010-06-06 15:50:29

I'll test with 1.6.2
By: Paul Belanger (pabelanger) 2010-06-18 10:01:33

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines