Summary:	ASTERISK-24844: chan_iax2: name of channels can cause Bridge action to use the wrong channels when bridging is made using the channel name
Reporter:	Alberto Sanchez Gonzalez (alberto.mu.es)	Labels:
Date Opened:	2015-03-04 01:54:48.000-0600	Date Closed:	2015-03-10 07:29:43
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2 Core/ManagerInterface
Versions:	11.6.1	Frequency of Occurrence	Occasional
Related Issues:
Environment:	ubuntu 12.04 running certified-asterisk-11.6-cert2	Attachments:	( 0) asterisk_bridge_channels_wronly_with_comments.txt
Description:	Sometimes happened to me that trying to make bridges, through AMI, some of them are made linking channels wrong that I said. For example, in a specific moment, I have next 4 channels to bridge, originate in such order, ch1 before ch2, ch2 before ch3, and so on: {noformat} ch1: dahdi/i1/123456789-c145 ch2: iax2/pbx8-19952 ch3: iax2/pbx8-19 ch4: iax2/pbx8-28577 {noformat} First, I tried to link ch1 and ch2: {noformat} action: bridge actionid: eee7463b-8897-4b1d-b12d-e82957a4c888 channel1: dahdi/i1/123456789-c145 channel2: iax2/pbx8-19952 {noformat} And is done ok: {noformat} event: bridgeaction privilege: call,all timestamp: 1414076642.188133 response: success channel1: dahdi/i1/123456789-c145 channel2: iax2/pbx8-19952 {noformat} Second, I tried to link ch3 and ch4 {noformat} action: bridge actionid: eee7463b-8897-4b1d-b12d-e82957a4c888 channel1: iax2/pbx8-19 channel2: iax2/pbx8-28577 {noformat} But in this case, instead of receive an ok with above channels, I've received: {noformat} action: bridge actionid: eee7463b-8897-4b1d-b12d-e82957a4c888 channel1: iax2/pbx8-19952 channel2: iax2/pbx8-28577 {noformat} Notice that the bridge were done between ch4 and ch2, instead of ch4 and ch3. We made a workaround of this issue launching the action bridges with their uniqueid's instead of channel name's. But I wanted to open an issue for your knowledge. I don't know if is known or not, I don't find it in the issue tracker. PD: We realized of this issue checking in the code, the function {{ast_channel_by_name_cb}} in main/channel.c, which matches channel names taking only the first part of the name. PD2: I'm really sorry because I don't have any AMI traces of this issue, happened time ago. PD3: Sorry for my English. I hope to be enough clear.
Comments:	By: Rusty Newton (rnewton) 2015-03-06 17:48:11.284-0600 Thanks for the report. Sounds like a bug, but you don't describe how to reproduce the issue? I'm wondering why others have not run into it. {quote} PD: We realized of this issue checking in the code, the function ast_channel_by_name_cb in main/channel.c, which matches channel names taking only the first part of the name. {quote} Would you like to provide a patch demonstrating your fix for the issue? https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process By: Rusty Newton (rnewton) 2015-03-06 17:48:29.658-0600 Remember to use "Enter Feedback" to send the issue back to us when you have replied. By: Alberto Sanchez Gonzalez (alberto.mu.es) 2015-03-10 03:20:15.833-0500 AMI Traces with the issue. Supposing we have a previous bridge between iax2/pbx8-22092 and iax2/pbx8-3748, this is the story: 1º) We launched a bridge between iax2/pbx8-22 and iax2/pbx8-22196 2º) Asterisk unlink iax2/pbx8-22092 and iax2/pbx8-3748 3º) Asterisk link iax2/pbx8-22196 and iax2/pbx8-22092, what is wrong! PD: I write down within the document all notes beginning with ### PD: I changes the callerid phones tpo 123456789 for privacy reasons. By: Alberto Sanchez Gonzalez (alberto.mu.es) 2015-03-10 03:21:43.877-0500 I've found the trace which shows what happened. I let you in attachment. According the patch, I didn't made no one, just made a workaround launching the bridges with the uniqueids instead of the channels. By: Matt Jordan (mjordan) 2015-03-10 07:28:38.956-0500 [~alberto.mu.es]: You are correct that this issue can occur with {{chan_iax2}} channels. This is due to their channel name construction, which - unlike other channel drivers (such as {{chan_sip}}) - does not use a monotonically increasing integer. Instead, it uses the {{callno}} of the channel, which is an IAX2 specific construct. Because the {{callno}} is not padded in the channel name, a {{callno}} for one channel (such as {{22}}) can be a string prefix for another channel (such as {{22196}}). As such, channel prefix lookups - which is how channels are looked up when provided by AMI and other APIs - can pick the wrong channel. In this case, I don't think we really want to change the behaviour, for the following reasons: # Changing this in {{chan_iax2}} would have some rather large ramifications, both for expected behaviour by people using the channel driver as well as for the ripple effect in the channel driver. # This primarily affects only {{chan_iax2}}. # Changing the lookup mechanism in {{channel.c}} would *definitely* have a major impact on consumers of the APIs. # There is a valid workaround by using the channel {{uniqueid}}, as you found. In fact, in some of the newer APIs - such as ARI - using the channel {{uniqueid}} is actually the preferred way to address a channel. As such, I'm going to close this out as Won't Fix, although I appreciate you filing the issue (which was very detailed as well - thanks!) - as this will definitely be useful for anyone else who runs into this problem.