[asterisk-bugs] [JIRA] (ASTERISK-26646) CoreShowChannel seems to intermittently get the same Uniqueid Linkedid

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234094#comment-234094 ] 

Richard Mudgett commented on ASTERISK-26646:
--------------------------------------------

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.

> CoreShowChannel seems to intermittently get the same Uniqueid Linkedid
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-26646
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26646
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/ManagerInterface
>    Affects Versions: 13.10.0
>         Environment: Gentoo, Vanilla Asterisk
>            Reporter: Troy Bowman
>            Severity: Minor
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)