Summary: | ASTERISK-26646: CoreShowChannel seems to intermittently get the same Uniqueid Linkedid | ||
Reporter: | Troy Bowman (troy) | Labels: | |
Date Opened: | 2016-12-06 13:13:21.000-0600 | Date Closed: | 2016-12-06 17:10:38.000-0600 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Core/ManagerInterface |
Versions: | 13.10.0 | Frequency of Occurrence | Frequent |
Related Issues: | |||
Environment: | Gentoo, Vanilla Asterisk | Attachments: | |
Description: | I seem to be intermittently getting the same Uniqueid and Linkedid for bridged channels from CoreShowChannels, for example:
Event: CoreShowChannel Channel: SIP/yak-00020025 ChannelState: 6 ChannelStateDesc: Up CallerIDNum: 9257274345 CallerIDName: Carlos Campos ConnectedLineNum: 0525 ConnectedLineName: Tanner Bills Language: en AccountCode: 1481048062.131383 Context: go_queueops Exten: s Priority: 12 Uniqueid: 1481048062.206932 Linkedid: 1481048062.206932 Application: Queue ApplicationData: contractor,,,clients,,,,go_queue_accept,, Duration: 00:02:14 BridgeId: e5443a38-fa3b-4060-870b-7cebd3a9767a I tried looking for a cause but I got lost in the rabbit hole as it seems to come from a deeply defined stasis channel cache of who knows what message. Sorry for not testing this on a later version, this is the version I'm running in production right now, and I can't really see any changes that may affect channel_state in later 13.13. | ||
Comments: | By: Asterisk Team (asteriskteam) 2016-12-06 13:13:21.961-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Troy Bowman (troy) 2016-12-06 13:21:53.477-0600 Seems to not be the manager, since "core show channel" in the console also gives duplicated IDs: Manger: Event: CoreShowChannel Channel: SIP/0313-000200d0 ChannelState: 6 ChannelStateDesc: Up CallerIDNum: 8016181494 CallerIDName: Patty Cazer ConnectedLineNum: 7046506171 ConnectedLineName: Esther Schilling Language: en AccountCode: 1481050885.207192 Context: macro-dialout Exten: s Priority: 9 Uniqueid: 1481050885.207192 Linkedid: 1481050885.207192 Application: Dial ApplicationData: SIP/17046506171@yak Duration: 00:17:09 BridgeId: 82de99bc-1569-4b8c-8bcd-b6fec02a707c Console: voip*CLI> core show channel SIP/0313-000200d0 -- General -- Name: SIP/0313-000200d0 Type: SIP UniqueID: 1481050885.207192 LinkedID: 1481050885.207192 Caller ID: 8016181494 Caller ID Name: Patty Cazer Connected Line ID: 7046506171 Connected Line ID Name: Esther Schilling Eff. Connected Line ID: 7046506171 Eff. Connected Line ID Name: Esther Schilling DNID Digits: 7046506171 Language: en State: Up (6) NativeFormats: (ulaw) WriteFormat: ulaw ReadFormat: ulaw WriteTranscode: No ReadTranscode: No Time to Hangup: 0 Elapsed Time: 0h17m57s Bridge ID: 82de99bc-1569-4b8c-8bcd-b6fec02a707c -- PBX -- Context: macro-dialout Extension: s Priority: 9 Call Group: 0 Pickup Group: 0 Application: Dial Data: SIP/17046506171@yak Call Identifer: [C-00013dca] Variables: BRIDGEPVTCALLID=68bfd8545edb926843d685b04324137e@192.168.252.2:5060 BRIDGEPEER=SIP/yak-000200d1 DIALEDPEERNUMBER=17046506171@yak DIALEDPEERNAME=SIP/yak-000200d1 DIALSTATUS=ANSWER DIALEDTIME= ANSWEREDTIME= MACRO_DEPTH=1 SIP_CODEC_OUTBOUND=ulaw SIP_CODEC_INBOUND=ulaw MACRO_PRIORITY=2 MACRO_CONTEXT=authorized-outgoing MACRO_EXTEN=7046506171 ARG1=17046506171 AGISTATUS=SUCCESS RCID=7046506171 RNAM=Esther Schilling NEW_CID=8016181494 ORIG_SRC=0313 SIPADDHEADER03=X-dest:17046506171 SIPADDHEADER02=X-from:0313 SIPADDHEADER01=X-accountcode:1481050885.207192 SIPCALLID=160b93cf-f0fc27fc-c6690fa5@192.168.252.221 SIPDOMAIN=sip.voip.te SIPURI=sip:0313@192.168.252.221 CDR Variables: level 1: calledsubaddr= level 1: callingsubaddr= level 1: dnid=7046506171 level 1: clid="Patty Cazer" <8016181494> level 1: src=8016181494 level 1: dst=s level 1: dcontext=macro-dialout level 1: channel=SIP/0313-000200d0 level 1: dstchannel=SIP/yak-000200d1 level 1: lastapp=Dial level 1: lastdata=SIP/17046506171@yak level 1: start=1481050885.726460 level 1: answer=1481050897.195821 level 1: end=0.000000 level 1: duration=1076 level 1: billsec=1065 level 1: disposition=8 level 1: amaflags=3 level 1: accountcode=1481050885.207192 level 1: uniqueid=1481050885.207192 level 1: linkedid=1481050885.207192 level 1: sequence=136680 By: Troy Bowman (troy) 2016-12-06 13:26:13.816-0600 I thought maybe it was because I'm setting the account code, but they don't always jive: Event: CoreShowChannel Channel: SIP/yak-0002010e ChannelState: 6 ChannelStateDesc: Up CallerIDNum: 8135312386 CallerIDName: Jessica Monique Williams ConnectedLineNum: 0576 ConnectedLineName: Corey Haraldson Language: en AccountCode: 1481052126.131611 Context: go_queueops Exten: s Priority: 12 Uniqueid: 1481052126.207287 Linkedid: 1481052126.207287 Application: Queue ApplicationData: contractor,,,support,,,,go_queue_accept,, Duration: 00:02:01 BridgeId: 3e5ed8c3-1ea2-4468-8c06-9416a4d59862 voip*CLI> core show channel SIP/yak-0002010e -- General -- Name: SIP/yak-0002010e Type: SIP UniqueID: 1481052126.207287 LinkedID: 1481052126.207287 Caller ID: 8135312386 Caller ID Name: Jessica Monique Williams Connected Line ID: 0576 Connected Line ID Name: Corey Haraldson Eff. Connected Line ID: 0576 Eff. Connected Line ID Name: Corey Haraldson DNID Digits: +18005184461 Language: en State: Up (6) NativeFormats: (ulaw) WriteFormat: ulaw ReadFormat: ulaw WriteTranscode: No ReadTranscode: No Time to Hangup: 0 Elapsed Time: 0h2m55s Bridge ID: 3e5ed8c3-1ea2-4468-8c06-9416a4d59862 -- PBX -- Context: go_queueops Extension: s Priority: 12 Call Group: 0 Pickup Group: 0 Application: Queue Data: contractor,,,support,,,,go_queue_accept,, Call Identifer: [C-00013df0] Variables: BRIDGEPVTCALLID=27ffe8585ccec873023807cb614e8a84@192.168.252.2:5060 BRIDGEPEER=SIP/0576-0002010f QUEUEPOSITION=1 QUEUESRVLEVELPERF=93.6 QUEUESRVLEVEL=30 QUEUEABANDONED=0 QUEUECOMPLETED=125 QUEUETALKTIME=444 QUEUEHOLDTIME=6 QUEUECALLS=2 QUEUESTRATEGY=rrmemory QUEUEMAX=10 QUEUENAME=contractor QEORIGINALPOS=1 QEHOLDTIME=16 MEMBERREALTIME=0 MEMBERDYNAMIC=1 MEMBERPENALTY=0 MEMBERLASTCALL=1481051461 MEMBERCALLS=3 MEMBERNAME=Phone/0576 Corey Haraldson MEMBERINTERFACE=SIP/0576 PLAYBACKSTATUS=SUCCESS QUEUE_MAX_PENALTY=0 QUEUE_MIN_PENALTY=0 ARGC=4 ARG4=contractor ARG3=0003 ARG2=support ARG1=contractor BACKGROUNDSTATUS=SUCCESS MACRO_DEPTH=0 AGISTATUS=SUCCESS SIPREDIRECTREASON=unconditional PRIREDIRECTREASON=UNCONDITIONAL SIPRDNISDOMAIN=192.168.252.12 SIPCALLID=755032fd7bc282ab32b40bed071df580@192.168.252.12:5060 SIPDOMAIN=sip.voip.te SIPURI=sip:+18135312386@192.168.252.12:5060 CDR Variables: level 1: calledsubaddr= level 1: callingsubaddr= level 1: dnid=+18005184461 level 1: clid="Jessica Monique Williams" <8135312386> level 1: src=8135312386 level 1: dst=s level 1: dcontext=go_queueops level 1: channel=SIP/yak-0002010e level 1: dstchannel=SIP/0576-0002010f level 1: lastapp=Queue level 1: lastdata=contractor,,,support,,,,go_queue_accept,, level 1: start=1481052126.709380 level 1: answer=1481052126.799507 level 1: end=0.000000 level 1: duration=174 level 1: billsec=174 level 1: disposition=8 level 1: amaflags=3 level 1: accountcode=1481052126.131611 level 1: uniqueid=1481052126.207287 level 1: linkedid=1481052126.207287 level 1: userfield="did=8005184461" level 1: sequence=136743 By: Richard Mudgett (rmudgett) 2016-12-06 13:54:03.599-0600 We appreciate the difficulties you are facing, however this does not appear to be a bug report and your request or comments would be better served in a different forum. The Asterisk community provides support over IRC, mailing lists, and forums as described at http://asterisk.org/community. The Asterisk issue tracker is used specifically to track issues concerning bugs and documentation errors. Please see the Asterisk Issue Guidelines [1] for instruction on the intended use of the Asterisk issue tracker. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines I'm not seeing a problem here and this sounds more like a support issue best handled elsewhere. * Before a channel is bridged the linkedid and uniqueid of a channel are the same. * The linkedid is the uniqueid of the oldest channel a channel has been bridged with. For normal calls this is usually the calling channel. * The accountcode is a string that you set for your own tracking purposes. By: Troy Bowman (troy) 2016-12-06 15:08:56.118-0600 But the channels *ARE* bridged. See the bridge id? It is empty before the channel is bridged! By: Troy Bowman (troy) 2016-12-06 15:09:37.954-0600 Of course the account code is for my own tracking purposes. I am not talking about that. By: Troy Bowman (troy) 2016-12-06 15:13:57.795-0600 I guess what you're saying is that Linkedid has nothing to do with the bridge and it is a remnant of the old architecture before the bridge revamp. If that's what it is, then nevermind. I'm sorry I wasted your time. By: Troy Bowman (troy) 2016-12-06 15:17:15.258-0600 Even if it is the oldest channel it has been bridged with, it is set to the same channel id before it has been bridged, and it retains that old same Linkedid afterwards. New channel before bridge: Event: CoreShowChannel Channel: SIP/0592-0002038b ChannelState: 4 ChannelStateDesc: Ring CallerIDNum: 3852444646 CallerIDName: Theo Ceasar ConnectedLineNum: 8653186652 ConnectedLineName: KNOXVILLE, TN Language: en AccountCode: 1481058889.208270 Context: macro-dialout Exten: s Priority: 9 Uniqueid: 1481058889.208270 Linkedid: 1481058889.208270 Application: Dial ApplicationData: SIP/18653186652@yak Duration: 00:00:02 BridgeId: Same channel after bridge: Event: CoreShowChannel Channel: SIP/0592-0002038b ChannelState: 6 ChannelStateDesc: Up CallerIDNum: 3852444646 CallerIDName: Theo Ceasar ConnectedLineNum: 8653186652 ConnectedLineName: KNOXVILLE, TN Language: en AccountCode: 1481058889.208270 Context: macro-dialout Exten: s Priority: 9 Uniqueid: 1481058889.208270 Linkedid: 1481058889.208270 Application: Dial ApplicationData: SIP/18653186652@yak Duration: 00:00:56 BridgeId: 58d59c26-901c-4d59-bc1d-3eb2c559571d By: Troy Bowman (troy) 2016-12-06 15:21:43.074-0600 If the above is by design, then feel free to close this ticket. It'd be nice if the Linkedid weren't worthless, though. I understand that the new bridge architecture probably deprecated Linkedid. By: Richard Mudgett (rmudgett) 2016-12-06 16:28:59.785-0600 Linkedid is not deprecated and is working as when it was initially created to find the oldest channel a channel has been associated with. In your example, the SIP/0592-0002038b channel is the original calling channel and thus is the *oldest* channel in the bridge since it started the call. SIP/A -> Dial(SIP/B) -> SIP/B SIP/A is the calling channel and thus it is older since it dialed SIP/B. When SIP/A is bridged with SIP/B then SIP/A's linkedid does not change because it is older than SIP/B. SIP/B's linkedid *is* changed to SIP/A's uniqueid because SIP/A is older. Now if SIP/B attended transfers SIP/A to SIP/C then the linkedid of SIP/C would initially be SIP/B's uniqueid until SIP/B completes the transfer to SIP/A. Then the linkedid of SIP/C would change to the uniqueid of SIP/A. What you seem to be wanting is the BRIDGEPEER channel variable value. That changes to reflect who a channel is currently bridged with. By: Troy Bowman (troy) 2016-12-06 17:10:38.690-0600 Thanks for explaining. I'm sorry I wasted your time. By: Rusty Newton (rnewton) 2016-12-06 17:18:38.983-0600 In the future it will help us out if you can attach debug via "More > Attach Files" (as .txt extension). All the debug in the comment fields results in a lot of scrolling and huge E-mail notifications. Thanks in advance! https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines |