Summary:	ASTERISK-11887: Queue language is not inherited or available to answering interface
Reporter:	Nick Barnes (bcnit)	Labels:
Date Opened:	2008-04-22 03:57:43	Date Closed:	2009-05-12 20:19:15
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The problem is that when an interface answers a call from a queue, the language used to play the 'announce' message to the callee is the default language for that interface and not the language defined in the channel which placed the call into the queue. This is not the case for the A() parameter in the Dial() application, which plays the file in the language of the source and not the destination interface. So if a call has the language set as 'fr' and is placed into the queue with 'Queue(one,,calltype)', for example, all the announcements to the caller are made in the 'fr' language, but when the language of the interface answering the call is 'en', they hear 'en/calltype' and not 'fr/calltype'. I see three ways around this problem. One of which I can probably hack together myself and two which I probably can't. The first is to create a variable 'QUEUELANGUAGE' when 'setqueuevar' is 'yes' and then have a macro/subroutine use this variable set the language on the answering channel as appropriate. The second would be to have some way of selectively inheriting the language from the calling channel. This one I have no idea how to implement!! The third would be to duplicate the behaviour of the A() parameter of the Dial() application and use the language from the caller's channel to play the announcement. I don't want to do anything without discussing this with everybody first, but I've just found a different bug which may make the first option even easier for me! So, what's the best way forward?
Comments:	By: Nick Barnes (bcnit) 2008-04-22 04:24:09 The first option isn't viable. The macro is run _after_ the announcement is made. A short term fix is to prefix the language onto the announcement as follows: Queue(queuename,,,${CHANNEL(language)}/calltype) which isn't ideal as this has to be done in the dialplan rather than just set announce=calltype within the queue definition. By: Nick Barnes (bcnit) 2008-04-22 06:43:04 Another reason why the first option isn't viable - the macro defined by 'membermacro' in the queue definition is run on the calling channel and not the called channel. By: Mark Michelson (mmichelson) 2008-04-24 16:02:56 I'm having trouble understanding what the problem is, here. A French-speaking caller calls a queue. While he is in the queue, he hears French sounds. An English-speaking queue member answers the call and hears an announce file in English. What you want is for the English-speaking queue member to hear the French version of the file since the caller is calling on a French-language channel. Did I get that right? If I did, then I'm not really sure how this is a bug. By: Nick Barnes (bcnit) 2008-04-28 09:38:40 The problem is that the A() option for the Dial() application plays the announce file in the source channel's language and the 'announceoverride' option for the Queue() application plays it in the destination channel's language. In our case, the call would be answered by a bi-lingual agent. If the announcement were in the language of the caller, it would tell them which language to speak. Anyway, it's no biggie to code around within the dialplan. I was just surprised when I found out that the Dial() and Queue() apps worked in different ways. By: Mark Michelson (mmichelson) 2008-05-05 15:17:10 You raise a very good point with regards to the inconsistency between Dial() and Queue(). I had a discussion with some folks and we came to the agreement that in the majority of cases that the current Queue() behavior is what is desired. I ran a test on the 1.4 branch and found that the same inconsistency exists there, too. My plan of action is *not* to change the 1.4 branch since that could potentially break the expected behaviors of established dialplans. For trunk, though, I will change the behavior of Dial() to reflect what Queue() does and place a note in UPGRADE.txt explaining the change as well as workarounds. By: Digium Subversion (svnbot) 2008-06-26 18:28:12 Repository: asterisk Revision: 125647 U   trunk/CHANGES U   trunk/apps/app_dial.c ------------------------------------------------------------------------ r125647 | mmichelson | 2008-06-26 18:28:09 -0500 (Thu, 26 Jun 2008) | 16 lines Improve consistency between app_dial and app_queue with regards to how language is handled between two channels whose native language is different. Prior to this patch, app_dial would have the callee inherit the caller's language, and app_queue would not. After this patch, app_dial no longer has the language inheritance capability. This seems to make the most sense since it seems more natural for a person to hear files played back in his/her native language instead of the language of the person on the far end of the call. See the CHANGES file for hints on how to keep the previous behavior of app_dial if desired. (closes issue ASTERISK-11887) Reported by: bcnit ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=125647 By: Digium Subversion (svnbot) 2008-06-26 18:28:54 Repository: asterisk Revision: 125648 _U  branches/1.6.0/ ------------------------------------------------------------------------ r125648 | mmichelson | 2008-06-26 18:28:53 -0500 (Thu, 26 Jun 2008) | 23 lines Blocked revisions 125647 via svnmerge ........ r125647 | mmichelson | 2008-06-26 18:35:29 -0500 (Thu, 26 Jun 2008) | 16 lines Improve consistency between app_dial and app_queue with regards to how language is handled between two channels whose native language is different. Prior to this patch, app_dial would have the callee inherit the caller's language, and app_queue would not. After this patch, app_dial no longer has the language inheritance capability. This seems to make the most sense since it seems more natural for a person to hear files played back in his/her native language instead of the language of the person on the far end of the call. See the CHANGES file for hints on how to keep the previous behavior of app_dial if desired. (closes issue ASTERISK-11887) Reported by: bcnit ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=125648