[Home]

Summary:ASTERISK-06229: MOH in "files" mode writes in wrong formats at certain times
Reporter:Justin R. Tunney (jtunney)Labels:
Date Opened:2006-02-01 13:14:08.000-0600Date Closed:2006-08-05 03:02:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-mohsqueel-r24494.patch
( 1) parklog.txt
Description:Cause #1: I put someone on hold with my budgetone.  They hear some lovely music and when I press the flash key, the music turns in to LOUD awful noise.

Cause #2: On my Mitel 5224 and Grandstream 4-line, I do an attended transfer to parking.  I hear the parked extension and music on hold starts playing.  If I transfer the call after MOH starts playing, the caller will hear awful noise.  If I transfer before MOH starts (during extension playback), the caller will hear normal MOH.

The following bug only applies to using native formats for music on hold, not mp3 music on hold.  Right now this patch only corrects MOH in "files" mode.  I am not sure if this happens when using "custom" mode.

canreinvite=no ; not 100% sure if this affects bug

musiconhold.conf:
[default]
mode=files
directory=/var/lib/asterisk/moh-native
random=yes

[root@xi03 src]# ls /var/lib/asterisk/moh-native/
gardenia.ul  sparrows.ul

Workarounds:

- Use mp3 music on hold and waste a little extra CPU
- Use a MOH class that isn't named default and use the SetMusicOnHold() command in your dialplan.  When transfering the call, Asterisk MIGHT get confused and think it should start MOH class 'default' and end up not finding it and play no music on hold instead of that awful noise.

****** ADDITIONAL INFORMATION ******

Disclaimer on file
Comments:By: Justin R. Tunney (jtunney) 2006-02-01 13:26:09.000-0600

whoops, sorry i forgot [patch]
By: jalsot (jalsot) 2006-02-11 12:03:35.000-0600

I see in your patch:
+; 'best' format will be chosen at playback time.  Do not mix
+; different formats in the same directory.

If I don't have to store different formats in the same directory, how should I use 'files' mode?
By: Justin R. Tunney (jtunney) 2006-02-13 07:23:10.000-0600

Point taken
By: Kevin P. Fleming (kpfleming) 2006-02-14 19:39:11.000-0600

Hmm... Architecturally, this seems wrong. One of the benefits of native file playback has been that you could have the same sounds files in a bunch of formats, and the proper ones would be chosen based on the holdee's channel format.

Can you describe the problem you feel you are solving by making this change?
By: Justin R. Tunney (jtunney) 2006-02-15 08:37:29.000-0600

Kevin, I thought the same thing myself but I was a bit confused when fixing this bug because struct mohclass has a member "format" for storing the write format and a filearray member for storing each file in your folder.  It would be impossible to properly set mohclass->format if there are multiple types of files.  I figured it would make more sense to implement as the struct was designed, especially considering that I couldn't think of a single case in which one would want different formats of music on hold.  After all, the whole point of native moh is to avoid transcoding.

If you'd like Kevin, I can re-do the patch so moh native will determine the format each time a new file is selected.  Or, at your option I can write it so mohclass contains a linked list of struct mohfile that will tell you the filename and format.
By: Justin R. Tunney (jtunney) 2006-02-15 13:36:59.000-0600

Actually Kevin you're totally right.  I took a closer look at the file.c functions and came up with a simpler solution that should be able to handle different types of files, choose the best and all that other good stuff built in to Asterisk.

The only minor problem left at the moment is after the transfer, the music on hold state from the parker is handed over to the parkee.
By: Serge Vecher (serge-v) 2006-05-03 10:48:29

jtunney: can you please update the patch for recent 1.2? Thanks...
By: Justin R. Tunney (jtunney) 2006-05-03 16:28:58

This is still an issue, I just managed to reproduce this issue on 1.2 rev 24494.  The attended transfer problem did not happen when my mitel transfered an analog phone, however it did happen when transfering a sip phone (see cause 2)

The patch still fixes things.
By: Justin R. Tunney (jtunney) 2006-05-03 16:48:48

I just tested trunk, this problem doesn't seem to be happening in 24604
By: Russell Bryant (russell) 2006-05-08 10:46:54

If it's fixed in the trunk, but not in 1.2, we should try to figure out what change did it.
By: Justin R. Tunney (jtunney) 2006-05-18 13:35:51

after a lot of divide and conquer...  I found that revision r7547 magically fixes this issue in trunk.  There were some modifications to channel.c regarding channel formats.  I didn't go too indepth to understand why.
By: Russell Bryant (russell) 2006-05-18 14:01:52

Thank you very much for tracking it down!  I'll lab this up and will get it fixed for 1.2 in the next couple of days.
By: Russell Bryant (russell) 2006-05-19 11:52:43

That revision doesn't appear to fix the problem for me.  I am still able to reproduce it in the trunk in revisions later than that.  I am still investigating ...
By: Russell Bryant (russell) 2006-05-19 14:22:45

I'm making this so it's not assigned to me, since that discourages others from looking at it.  :)
By: Kevin P. Fleming (kpfleming) 2006-06-01 16:45:50

That 'format' field in the mohclass structure is only used for non-file-playback modes, so it is irrelevant to this issue.
By: Kevin P. Fleming (kpfleming) 2006-06-01 17:05:17

Can you guys test again with branch-1.2 and/or trunk with the changes that I committed today (which basically were the equivalent of this patch, but for a different reason)?
By: Justin R. Tunney (jtunney) 2006-06-01 17:52:56

seems to be working :)
By: Serge Vecher (serge-v) 2006-06-01 18:22:16

jtunney, thanks for testing quickly and thanks to kpf for fixing :). Fixed in 1.2 r31555 and trunk r31556 ...


By: Russell Bryant (russell) 2006-06-01 18:56:56

I did not see the original issue where you would hear distorted audio, but this code is still not quite right.  I have attached a call log of two call situations - one without and one with LOG_DEBUG enabled.  I wanted to post all of this information here so that I don't forget to look into it when I have time, or in case someone else has a chance to figure it out.

For reference, both SIP phones are using ULAW (codec 4) and my musiconhold files are in GSM (codec 2).

1)
- SIP/Cisco1 calls SIP/poly1
- Cisco1 does a SIP attended transfer of poly1 to parking
- poly1 loses musiconhold once the transfer is complete
At some point in this process, a channel expecting ulaw is given GSM frames.

2)
- SIP/Cisco1 calls Zap/2
- Cisco1 does a SIP attended transfer of Zap/2 to parking
- The Zap channel is automatically hung up and given congestion (though that isn't clear from CLI trace) because chan_zap receives GSM frames and has no idea what to do with them
By: Russell Bryant (russell) 2006-08-05 03:02:55

I think this has been fixed since my last notes here