[Home]

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-0600Date Closed:2016-12-06 17:10:38.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:13.10.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Gentoo, Vanilla AsteriskAttachments:
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