Summary:	ASTERISK-18238: local channel doesn't use language of requestor channel
Reporter:	Alan (lameventanas)	Labels:
Date Opened:	2011-08-08 03:54:19	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_local
Versions:	1.8.5.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:	is duplicated by ASTERISK-26820 local channel doesn't respect default language setting in asterisk.conf
Environment:	Linux	Attachments:	( 0) chan_local-language.diff
Description:	In my scenario I originate a call from via the manager interface (AMI). I create the channel using something like this: Action: Originate Channel: Local/01@to-forward/n Context: to-newcall-record Extension: s Priority: 1 Async: 1 I always get english sounds, even though I have configured the "defaultlanguage" in /etc/asterisk/asterisk.conf to something else. Since there is no configuration file for the local channel, I assumed the the default in asterisk.conf would take effect, but it doesn't.
Comments:	By: Mark Petersen (roadkill) 2012-03-06 06:48:30.803-0600 [Incoming] exten => 000,1,NoOP(${CHANNEL(language)}) exten => 000,n,Dial(Local/000@Test) exten => 000,n,NoOP(${CHANNEL(language)}) exten => 000,n,Hangup() [Test] exten => 000,1,NoOP(${CHANNEL(language)}) exten => 000,n,Hangup() [2012-02-17 10:56:35.899] – Executing [000@Incoming:1] NoOp("SIP/781-000413260263-1-00000531", "da") in new stack [2012-02-17 10:56:35.900] – Executing [000@Incoming:2] Dial("SIP/781-000413260263-1-00000531", "Local/000@Test") in new stack [2012-02-17 10:56:35.923] – Called Local/000@Test [2012-02-17 10:56:35.923] – Executing [000@Test:1] NoOp("Local/000@Test-f124;2", "en") in new stack [2012-02-17 10:56:35.926] – Executing [000@Test:2] Hangup("Local/000@Test-f124;2", "") in new stack [2012-02-17 10:56:35.926] == Spawn extension (Test, 000, 2) exited non-zero on 'Local/000@Test-f124;2' [2012-02-17 10:56:35.942] – No one is available to answer at this time (1:0/0/0) [2012-02-17 10:56:35.948] – Executing [000@Incoming:3] NoOp("SIP/781-000413260263-1-00000531", "da") in new stack [2012-02-17 10:56:35.950] – Executing [000@Incoming:4] Hangup("SIP/781-000413260263-1-00000531", "") in new stack By: Alan (lameventanas) 2012-03-06 07:00:08.262-0600 You just posted a piece of configuration and a log file with no further information, this doesn't help anyone. Furthermore, it seems like you didn't understand the problem, but there is no way to confirm it since you didn't type anything. By: Mark Petersen (roadkill) 2012-03-19 09:18:58.426-0500 Hi allan I postet how to duplicate the error with only 6 line of code using Local channel the main reason is my bug report with all the detail was just closed as a duplicate of this so either the person that closed my bug report dont understand the problem or don't care By: Olle Johansson (oej) 2012-04-23 09:52:44.246-0500 Have a fix for Mark's issue. By: Olle Johansson (oej) 2012-04-23 09:54:22.915-0500 Fix so that the new channel inherits language from the pbx channel. By: Olle Johansson (oej) 2012-04-23 10:07:51.031-0500 I still try to find why that patch is needed. Musicclass seems to be copied properly but not language. By: Marek Cervenka (cervajs) 2012-12-05 09:23:00.644-0600 i have the same problem. patch doesnt help   [CC] chan_local.c -> chan_local.o chan_local.c: In function local_new: chan_local.c:1193: error: requestor undeclared (first use in this function) chan_local.c:1193: error: (Each undeclared identifier is reported only once chan_local.c:1193: error: for each function it appears in.) chan_local.c:1194: error: chan undeclared (first use in this function) make[1]: *** [chan_local.o] Error 1 make: *** [channels] Error 2 By: François Beaulieu (fbeaulieu) 2015-02-04 13:45:49.892-0600 We're still experiencing this issue in version 1.8.32.1. The patch supplied above is not detailed enough and patch is thus applying it to the wrong function. This is the issue that cervajs is having above. I have adapted the patch to more recent 1.8 versions, and it does appear to solve the issues. I will need to make more tests to make sure it doesn't break anything, though. Has any progress been made in integrating this fix into the main branch? By: Matt Jordan (mjordan) 2015-02-04 14:10:49.137-0600 Asterisk 1.8 will only receive security fixes now. Preferably, a patch should be made for Asterisk 11, if this is still an issue in that version. That being said, I'm not sure why this patch is needed, or why this would be an issue. Local channels are created using {{ast_channel_alloc}}, which set the language on the channel to {{ast_defaultlanguage}}. {{ast_defaultlanguage}} is set to the value of {{defaultlanguage}} in {{asterisk.conf}} - so assuming that the default language has been set to something other than {{en}}, Local channels should already have that value. Pulling it over from the requesting channel shouldn't be necessary. By: François Beaulieu (fbeaulieu) 2015-02-04 14:22:01.848-0600 I don't currently have any asterisk 11+ builds in my lab to verify if this is still an issue, but unless there's been a heavy rewrite of the local channel driver, I suspect it will be. I will see if I can apply it to a recent build. It's necessary to pull the language from the requesting channel, as that channel may have been set to a language other than the system default. That would often be the case for multi-user and, especially, multi-tenant setups. In any case, it appears that it doesn't even pull it from the system default if the default has been changed from English. By: Matt Jordan (mjordan) 2015-02-04 14:27:14.291-0600 {quote} It's necessary to pull the language from the requesting channel, as that channel may have been set to a language other than the system default. That would often be the case for multi-user and, especially, multi-tenant setups. In any case, it appears that it doesn't even pull it from the system default if the default has been changed from English. {quote} True, but that isn't what the title of this issue is: "local channel doesn't respect default language setting in asterisk.conf" It isn't a bug for a Local channel to not use the requesting channel's language. It is a bug if it does not use the value in {{asterisk.conf}}. (Note: it may be an improvement for it to use the requesting channel's language, but that's hardly the same problem as what is described here) If you need to change the language on the Local channel(s), then just change it using the [CHANNEL|https://wiki.asterisk.org/wiki/display/AST/Function_CHANNEL] function. By: François Beaulieu (fbeaulieu) 2015-02-04 17:02:50.579-0600 {quote} it may be an improvement for it to use the requesting channel's language, but that's hardly the same problem as what is described here {quote} Ok, I see what you're saying. I'll consider filing a separate enhancement request. In the meantime I can confirm that the ast_channel struct has changed sufficiently in Asterisk11+ that the patch causes compilation issues and will need to be adapted, should the default language issue still be there (which I have not yet confirmed.) By: Nicolò Mazzon (nmazzon) 2017-02-24 11:05:45.976-0600 I have the same problem on 13.13.1. By: François Beaulieu (fbeaulieu) 2017-02-24 12:19:13.905-0600 Nicolo, I suggest you open a new ticket on that and refer to this one.