Summary:	ASTERISK-07327: Music-on-hold from files switches files toward outside caller during SIP transfer-to-Park
Reporter:	Jeff Saxe (jeffsaxe)	Labels:
Date Opened:	2006-07-12 08:29:52	Date Closed:	2011-06-07 14:07:25
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_musiconhold
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	A relatively minor problem, considering all that's wonderful about Asterisk, but something that callers and system users might notice and think odd. Music on hold can be performed with a sound card input, in which case every caller on hold hears the same thing (perhaps within a few milliseconds of buffer). Or, it can be performed by reading either MP3 or (my preference) native-format files from a directory; in this case, each caller gets a separate MOH file and even file pointer, so that if she is put on hold a few times over the course of a call, the music picks up right where it left off (this itself an effect that some callers might find strange). Anyway, when the internal Asterisk user transfers an outside caller (with SIP attended transfer, I'm talking about) to a Park slot, to hand off the call to somewhere else in the office, the outside caller bizarrely is treated to two different MOH streams. First, the internal user hits Transfer; he gets dial tone, and the caller gets an immediate MOH stream. The internal user dials the Park extension, and Alison Smith's voice reads off the parking slot number. Then the internal user gets music on hold as well, but it's another stream, randomly chosen from the files in the MOH directory. But the internal user doesn't really listen to this hold music -- it's just a placeholder after the Park program has announced the slot number. Then the internal user hits Transfer to complete the transfer, and the outside caller is bridged up with the result of the Park, so the first MOH stream is forgotten about, and the caller now gets dropped into the middle of the second stream. Since the whole process only takes several seconds, what the outside caller hears is "hold on a moment, I'll find Jim for you...", then several seconds of one piece of music (or announcements), then a quick, jarring transition to a different piece of music (or announcement). In fact, if there is only one file in the MOH directory, like a single sound file that's designed to play in an infinite loop, the caller will hear the first few seconds of that file, and then the same file will start again. Odd-sounding. I have no idea how difficult it would be to migrate the MOH file number and pointer variables from one side of the transfer to the other -- this might be a very tall order, given the internal structure of Asterisk, channels, Park, etc. But since in general it doesn't matter what precise music is playing on hold for any given caller, I think it's worth a few moments of effort to try to get the same music to play toward the same caller during this particular, and very common, transfer scenario. Thanks. I categorized this as "musiconhold", but feel free to re-classify it as a bug with Park if that's where the logic better lies.
Comments:	By: Serge Vecher (serge-v) 2006-09-01 14:12:47 JeffSaxe: music-on-hold has undergone major changes in trunk (1.4 soon to be). Did you have a chance to check it out? By: Jeff Saxe (jeffsaxe) 2006-09-04 19:10:12 No, I haven't yet, sorry. We do actually use the one-long-loop style of hold music, with a single 4-minute WAV file that is intended to play continuously; in fact, we specifically paid a production company to mix this together for us, and it's kind of a waste of money to have callers only ever hear the first half-minute of it! So I actually solved this another way, following instructions on the AstRecipes site to use "custom" mode and a one-line shell script that "cat"s out .raw files from a directory. This results in only one MOH stream being supplied to all channels, so the Transfer-to-Park behavior is completely seamless to the outside caller, and it's just as low in CPU use as the "native" MOH mode. I'm completely satisfied, so I never researched or monitored it any further. When 1.4 comes out, I'll look at the changed MOH behavior or options. In the meantime, you certainly don't need to keep this bug open on my account. Thanks! By: Joshua C. Colp (jcolp) 2006-09-07 22:14:22 Closed per request of reporter, but it does bring up an excellent point. Thanks for the lengthy explanation!