Calum Power
2018-Oct-03 05:18 UTC
[asterisk-users] Non-matching linkedid on CDR Records [SEC=UNCLASSIFIED]
Hi asterisk-users,
We have recently moved to the 13.x branch of Asterisk from 11.x, and we're
trying to correlate CDR records from multiple-legs for billing purposes.
As part of this change we have added 'linkedid' to our CDR table schema
in an attempt to join the multiple records into one billable record.
The call path can be simplified as (transport types in brackets):
SIP Phone---(SIP)---Asterisk Svr1---(IAX)---Asterisk Svr2---(IAX)---Asterisk
Svr3---(SIP)---PSTN
As per the CDR spec, I expected the 'linkedid' to propagate between the
records and be the same throughout...
However, we observe differing linkedid values for the same call... Thus
(xxx's added for privacy):
| id | calldate | src | dst | accountcode |
uniqueid | linkedid | billsec | duration |
| 5031920 | 2018-10-03 01:51:41 | 0362xxxxxx | 0449xxxxxx | |
1538531501.18974 | 1538531501.18974 | 64 | 71 |
| 5031921 | 2018-10-03 01:52:52 | 6613 | 0449xxxxxx | 759553 |
1538531488.11368 | 1538531488.11368 | 0 | 0 |
Noting that our out-dial from Svr2 changes the CLID to 0362xxxxxx as we must
present that CLID to our PSTN upstream provider as per their requirements.
The first record is taken from Asterisk Svr2, the second from Asterisk Svr1
(Svr1 replicates MySQL to Svr2)
As you can see, the linkedid records are different (1538531501.18974 vs
1538531488.11368)
The difference appears to be the matter of microsecs that it takes to connect
the call legs (over a satellite connection) so I could probably 'guess'
that these two are the same call, however for billing purposes this is not
accurate enough.
Can someone shed some light on why the linkedid is not being shared between IAX
channels?
Cheers,
Calum
___________________________________________________________________________
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209
and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20181003/cb8ced0d/attachment.html>
Richard Mudgett
2018-Oct-03 12:33 UTC
[asterisk-users] Non-matching linkedid on CDR Records [SEC=UNCLASSIFIED]
On Wed, Oct 3, 2018 at 12:20 AM Calum Power <Calum.Power at aad.gov.au> wrote:> Hi asterisk-users, > > We have recently moved to the 13.x branch of Asterisk from 11.x, and we're > trying to correlate CDR records from multiple-legs for billing purposes. > As part of this change we have added 'linkedid' to our CDR table schema in > an attempt to join the multiple records into one billable record. > > The call path can be simplified as (transport types in brackets): > SIP Phone---(SIP)---Asterisk Svr1---(IAX)---Asterisk > Svr2---(IAX)---Asterisk Svr3---(SIP)---PSTN > > As per the CDR spec, I expected the 'linkedid' to propagate between the > records and be the same throughout... > However, we observe differing linkedid values for the same call... Thus > (xxx's added for privacy): > | id | calldate | src | dst | > accountcode | uniqueid | linkedid | billsec | duration | > | 5031920 | 2018-10-03 01:51:41 | 0362xxxxxx | 0449xxxxxx > | | 1538531501.18974 | 1538531501.18974 | 64 | 71 | > | 5031921 | 2018-10-03 01:52:52 | 6613 | 0449xxxxxx | > 759553 | 1538531488.11368 | 1538531488.11368 | 0 | 0 | > > Noting that our out-dial from Svr2 changes the CLID to 0362xxxxxx as we > must present that CLID to our PSTN upstream provider as per their > requirements. > > The first record is taken from Asterisk Svr2, the second from Asterisk > Svr1 (Svr1 replicates MySQL to Svr2) > As you can see, the linkedid records are different (1538531501.18974 vs > 1538531488.11368) > > The difference appears to be the matter of microsecs that it takes to > connect the call legs (over a satellite connection) so I could probably > 'guess' that these two are the same call, however for billing purposes this > is not accurate enough. > > Can someone shed some light on why the linkedid is not being shared > between IAX channels? >Linkedid is not propagated between Asterisk boxes. A linkedid is just the uniqueid of the oldest associated channel within the Asterisk box. Uniqueid's are unique within an Asterisk box and can be made unique across Asterisk boxes by optionally adding the host name. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20181003/960a4bab/attachment-0001.html>
Calum Power
2018-Oct-08 05:09 UTC
[asterisk-users] Non-matching linkedid on CDR Records [SEC=UNCLASSIFIED]
Hi all,
Just thought I'd update this thread in case anyone else is Googling trying
to find out how to do this...
I found the solution to my problem to be to use the IAXVAR() function to pass
the accountcode between the Asterisk boxen and update the CHANNEL(accountcode)
with that variable.
Thanks to Richard @ Digium for the reply that clarified my misunderstanding.
Calum
On Wed, 2018-10-03 at 07:33 -0500, Richard Mudgett wrote:
On Wed, Oct 3, 2018 at 12:20 AM Calum Power <Calum.Power at
aad.gov.au<mailto:Calum.Power at aad.gov.au>> wrote:
Hi asterisk-users,
We have recently moved to the 13.x branch of Asterisk from 11.x, and we're
trying to correlate CDR records from multiple-legs for billing purposes.
As part of this change we have added 'linkedid' to our CDR table schema
in an attempt to join the multiple records into one billable record.
The call path can be simplified as (transport types in brackets):
SIP Phone---(SIP)---Asterisk Svr1---(IAX)---Asterisk Svr2---(IAX)---Asterisk
Svr3---(SIP)---PSTN
As per the CDR spec, I expected the 'linkedid' to propagate between the
records and be the same throughout...
However, we observe differing linkedid values for the same call... Thus
(xxx's added for privacy):
| id | calldate | src | dst | accountcode |
uniqueid | linkedid | billsec | duration |
| 5031920 | 2018-10-03 01:51:41 | 0362xxxxxx | 0449xxxxxx | |
1538531501.18974 | 1538531501.18974 | 64 | 71 |
| 5031921 | 2018-10-03 01:52:52 | 6613 | 0449xxxxxx | 759553 |
1538531488.11368 | 1538531488.11368 | 0 | 0 |
Noting that our out-dial from Svr2 changes the CLID to 0362xxxxxx as we must
present that CLID to our PSTN upstream provider as per their requirements.
The first record is taken from Asterisk Svr2, the second from Asterisk Svr1
(Svr1 replicates MySQL to Svr2)
As you can see, the linkedid records are different (1538531501.18974 vs
1538531488.11368)
The difference appears to be the matter of microsecs that it takes to connect
the call legs (over a satellite connection) so I could probably 'guess'
that these two are the same call, however for billing purposes this is not
accurate enough.
Can someone shed some light on why the linkedid is not being shared between IAX
channels?
Linkedid is not propagated between Asterisk boxes. A linkedid is just the
uniqueid of the oldest associated channel
within the Asterisk box. Uniqueid's are unique within an Asterisk box and
can be made unique across Asterisk boxes
by optionally adding the host name.
Richard
___________________________________________________________________________
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209
and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20181008/a3a73e21/attachment.html>