Vinicius Fontes
2015-Mar-26 15:24 UTC
[asterisk-users] CDR dst value null after attended transfer
I'm having an issue with CDR. Basically, I expect to have all
"legs" of a
call having the same linkedid and differing only by the sequence value.
That does happen, but I'm getting null dst values after doing an attended
transfer.
I'm not sure if this is a bug or I'm doing something wrong. I'm
running
Asterisk 13.2.0.
Here's the console log, step by step:
First, I receive a call from 5491549116 on extension 7051 (DID 5421047051):
[Mar 26 12:11:04] == Using SIP RTP TOS bits 184
[Mar 26 12:11:04] == Using SIP RTP CoS mark 5
[Mar 26 12:11:04] -- Executing [5421047051 at restrito:1]
Goto("SIP/pabx-e1-00000252", "interno,7051,1") in new stack
[Mar 26 12:11:04] -- Goto (interno,7051,1)
[Mar 26 12:11:04] -- Executing [7051 at interno:1]
Macro("SIP/pabx-e1-00000252", "stdexten,7051,SIP/7051") in
new stack
[Mar 26 12:11:04] -- Executing [s at macro-stdexten:1]
NoOp("SIP/pabx-e1-00000252", "STDEXTEN: Arg1 = 7051 Arg2 =
SIP/7051
Arg3 = ") in new stack
[Mar 26 12:11:04] -- Executing [s at macro-stdexten:2]
Dial("SIP/pabx-e1-00000252", "SIP/7051,45,tT") in new stack
[Mar 26 12:11:04] == Using SIP RTP TOS bits 184
[Mar 26 12:11:04] == Using SIP RTP CoS mark 5
[Mar 26 12:11:04] -- Called SIP/7051
[Mar 26 12:11:05] -- SIP/7051-00000253 is ringing
[Mar 26 12:11:11] -- SIP/7051-00000253 answered SIP/pabx-e1-00000252
[Mar 26 12:11:11] -- Channel SIP/pabx-e1-00000252 joined
'simple_bridge' basic-bridge
<b1c97b75-bd5f-4762-96dd-7aa68c472827>
[Mar 26 12:11:11] -- Channel SIP/7051-00000253 joined
'simple_bridge'
basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827>
Now, extension 7051 places the call on hold and calls 7003, who answers:
[Mar 26 12:11:17] -- Started music on hold, class 'default', on
channel
'SIP/pabx-e1-00000252'
[Mar 26 12:11:20] == Using SIP RTP TOS bits 184
[Mar 26 12:11:20] == Using SIP RTP CoS mark 5
[Mar 26 12:11:20] -- Executing [7003 at ddi:1]
Macro("SIP/7051-00000254",
"stdexten,7003,SIP/7003") in new stack
[Mar 26 12:11:20] -- Executing [s at macro-stdexten:1]
NoOp("SIP/7051-00000254", "STDEXTEN: Arg1 = 7003 Arg2 =
SIP/7003 Arg3 ") in new stack
[Mar 26 12:11:20] -- Executing [s at macro-stdexten:2]
Dial("SIP/7051-00000254", "SIP/7003,45,tT") in new stack
[Mar 26 12:11:20] == Using SIP RTP TOS bits 184
[Mar 26 12:11:20] == Using SIP RTP CoS mark 5
[Mar 26 12:11:20] -- Called SIP/7003
[Mar 26 12:11:20] -- SIP/7003-00000255 is ringing
[Mar 26 12:11:25] -- SIP/7003-00000255 answered SIP/7051-00000254
[Mar 26 12:11:25] -- Channel SIP/7051-00000254 joined
'simple_bridge'
basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2>
[Mar 26 12:11:25] -- Channel SIP/7003-00000255 joined
'simple_bridge'
basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2>
Then, extension 7051 transfers the call to 7003, who hangs up after a few
seconds:
[Mar 26 12:11:32] -- Channel SIP/pabx-e1-00000252 left
'simple_bridge'
basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827>
[Mar 26 12:11:32] -- Channel SIP/7051-00000254 left 'simple_bridge'
basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2>
[Mar 26 12:11:32] -- Channel SIP/pabx-e1-00000252 swapped with
SIP/7051-00000254 into 'simple_bridge' basic-bridge
<f4fb9d99-24b9-4d3c-9b63-41a1b84484b2>
[Mar 26 12:11:32] -- Stopped music on hold on SIP/pabx-e1-00000252
[Mar 26 12:11:32] -- Channel SIP/7051-00000253 left 'simple_bridge'
basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827>
[Mar 26 12:11:32] == Spawn extension (macro-stdexten, s, 2) exited
non-zero on 'SIP/7051-00000254' in macro 'stdexten'
[Mar 26 12:11:32] == Spawn extension (ddi, 7003, 1) exited non-zero on
'SIP/7051-00000254'
[2015-03-26 12:11:32] WARNING[1561][C-0000015c]: channel.c:5070 ast_write:
Codec mismatch on channel SIP/pabx-e1-00000252 setting write format to slin
from alaw native formats (alaw)
[Mar 26 12:11:40] -- Channel SIP/pabx-e1-00000252 left
'simple_bridge'
basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2>
[Mar 26 12:11:40] == Spawn extension (macro-stdexten, s, 2) exited
non-zero on 'SIP/pabx-e1-00000252' in macro 'stdexten'
[Mar 26 12:11:40] == Spawn extension (interno, 7051, 1) exited non-zero
on 'SIP/pabx-e1-00000252'
[Mar 26 12:11:40] -- Channel SIP/7003-00000255 left 'simple_bridge'
basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2>
So far so good, except that when I check the CDR lines generated, this is
what I get:
mysql> select calldate, uniqueid, linkedid, sequence, src, dst, duration,
disposition, channel, dstchannel from cdr where uniqueid =
'1427382664.963';
+---------------------+----------------+----------------+----------+------------+------+----------+-------------+----------------------+-------------------+
| calldate | uniqueid | linkedid | sequence | src
| dst | duration | disposition | channel | dstchannel
|
+---------------------+----------------+----------------+----------+------------+------+----------+-------------+----------------------+-------------------+
| 2015-03-26 12:11:04 | 1427382664.963 | 1427382664.963 | 645 |
5491549116 | 7051 | 27 | ANSWERED | SIP/pabx-e1-00000252 |
SIP/7051-00000253 |
| 2015-03-26 12:11:32 | 1427382664.963 | 1427382664.963 | 649 |
5491549116 | | 7 | ANSWERED | SIP/pabx-e1-00000252 |
SIP/7003-00000255 |
+---------------------+----------------+----------------+----------+------------+------+----------+-------------+----------------------+-------------------+
2 rows in set (0.62 sec)
Notice how the dst field on the second line is missing.
Am I doing something wrong here or this is a bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20150326/591824a8/attachment.html>
Matthew Jordan
2015-Mar-26 16:53 UTC
[asterisk-users] CDR dst value null after attended transfer
On Thu, Mar 26, 2015 at 10:24 AM, Vinicius Fontes <vinicius at aittelecom.com.br> wrote:> I'm having an issue with CDR. Basically, I expect to have all "legs" of a > call having the same linkedid and differing only by the sequence value. That > does happen, but I'm getting null dst values after doing an attended > transfer. > > I'm not sure if this is a bug or I'm doing something wrong. I'm running > Asterisk 13.2.0. > > Here's the console log, step by step: > > First, I receive a call from 5491549116 on extension 7051 (DID 5421047051): > > [Mar 26 12:11:04] == Using SIP RTP TOS bits 184 > [Mar 26 12:11:04] == Using SIP RTP CoS mark 5 > [Mar 26 12:11:04] -- Executing [5421047051 at restrito:1] > Goto("SIP/pabx-e1-00000252", "interno,7051,1") in new stack > [Mar 26 12:11:04] -- Goto (interno,7051,1) > [Mar 26 12:11:04] -- Executing [7051 at interno:1] > Macro("SIP/pabx-e1-00000252", "stdexten,7051,SIP/7051") in new stack > [Mar 26 12:11:04] -- Executing [s at macro-stdexten:1] > NoOp("SIP/pabx-e1-00000252", "STDEXTEN: Arg1 = 7051 Arg2 = SIP/7051 Arg3 > = ") in new stack > [Mar 26 12:11:04] -- Executing [s at macro-stdexten:2] > Dial("SIP/pabx-e1-00000252", "SIP/7051,45,tT") in new stack > [Mar 26 12:11:04] == Using SIP RTP TOS bits 184 > [Mar 26 12:11:04] == Using SIP RTP CoS mark 5 > [Mar 26 12:11:04] -- Called SIP/7051 > [Mar 26 12:11:05] -- SIP/7051-00000253 is ringing > [Mar 26 12:11:11] -- SIP/7051-00000253 answered SIP/pabx-e1-00000252 > [Mar 26 12:11:11] -- Channel SIP/pabx-e1-00000252 joined 'simple_bridge' > basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827> > [Mar 26 12:11:11] -- Channel SIP/7051-00000253 joined 'simple_bridge' > basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827> > > Now, extension 7051 places the call on hold and calls 7003, who answers: > > [Mar 26 12:11:17] -- Started music on hold, class 'default', on channel > 'SIP/pabx-e1-00000252' > [Mar 26 12:11:20] == Using SIP RTP TOS bits 184 > [Mar 26 12:11:20] == Using SIP RTP CoS mark 5 > [Mar 26 12:11:20] -- Executing [7003 at ddi:1] Macro("SIP/7051-00000254", > "stdexten,7003,SIP/7003") in new stack > [Mar 26 12:11:20] -- Executing [s at macro-stdexten:1] > NoOp("SIP/7051-00000254", "STDEXTEN: Arg1 = 7003 Arg2 = SIP/7003 Arg3 > ") in new stack > [Mar 26 12:11:20] -- Executing [s at macro-stdexten:2] > Dial("SIP/7051-00000254", "SIP/7003,45,tT") in new stack > [Mar 26 12:11:20] == Using SIP RTP TOS bits 184 > [Mar 26 12:11:20] == Using SIP RTP CoS mark 5 > [Mar 26 12:11:20] -- Called SIP/7003 > [Mar 26 12:11:20] -- SIP/7003-00000255 is ringing > [Mar 26 12:11:25] -- SIP/7003-00000255 answered SIP/7051-00000254 > [Mar 26 12:11:25] -- Channel SIP/7051-00000254 joined 'simple_bridge' > basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2> > [Mar 26 12:11:25] -- Channel SIP/7003-00000255 joined 'simple_bridge' > basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2> > > > Then, extension 7051 transfers the call to 7003, who hangs up after a few > seconds: > > [Mar 26 12:11:32] -- Channel SIP/pabx-e1-00000252 left 'simple_bridge' > basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827> > [Mar 26 12:11:32] -- Channel SIP/7051-00000254 left 'simple_bridge' > basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2> > [Mar 26 12:11:32] -- Channel SIP/pabx-e1-00000252 swapped with > SIP/7051-00000254 into 'simple_bridge' basic-bridge > <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2> > [Mar 26 12:11:32] -- Stopped music on hold on SIP/pabx-e1-00000252 > [Mar 26 12:11:32] -- Channel SIP/7051-00000253 left 'simple_bridge' > basic-bridge <b1c97b75-bd5f-4762-96dd-7aa68c472827> > [Mar 26 12:11:32] == Spawn extension (macro-stdexten, s, 2) exited > non-zero on 'SIP/7051-00000254' in macro 'stdexten' > [Mar 26 12:11:32] == Spawn extension (ddi, 7003, 1) exited non-zero on > 'SIP/7051-00000254' > [2015-03-26 12:11:32] WARNING[1561][C-0000015c]: channel.c:5070 ast_write: > Codec mismatch on channel SIP/pabx-e1-00000252 setting write format to slin > from alaw native formats (alaw) > [Mar 26 12:11:40] -- Channel SIP/pabx-e1-00000252 left 'simple_bridge' > basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2> > [Mar 26 12:11:40] == Spawn extension (macro-stdexten, s, 2) exited > non-zero on 'SIP/pabx-e1-00000252' in macro 'stdexten' > [Mar 26 12:11:40] == Spawn extension (interno, 7051, 1) exited non-zero on > 'SIP/pabx-e1-00000252' > [Mar 26 12:11:40] -- Channel SIP/7003-00000255 left 'simple_bridge' > basic-bridge <f4fb9d99-24b9-4d3c-9b63-41a1b84484b2> > > So far so good, except that when I check the CDR lines generated, this is > what I get: > > mysql> select calldate, uniqueid, linkedid, sequence, src, dst, duration, > disposition, channel, dstchannel from cdr where uniqueid = '1427382664.963'; > +---------------------+----------------+----------------+----------+------------+------+----------+-------------+----------------------+-------------------+ > | calldate | uniqueid | linkedid | sequence | src > | dst | duration | disposition | channel | dstchannel | > +---------------------+----------------+----------------+----------+------------+------+----------+-------------+----------------------+-------------------+ > | 2015-03-26 12:11:04 | 1427382664.963 | 1427382664.963 | 645 | > 5491549116 | 7051 | 27 | ANSWERED | SIP/pabx-e1-00000252 | > SIP/7051-00000253 | > | 2015-03-26 12:11:32 | 1427382664.963 | 1427382664.963 | 649 | > 5491549116 | | 7 | ANSWERED | SIP/pabx-e1-00000252 | > SIP/7003-00000255 | > +---------------------+----------------+----------------+----------+------------+------+----------+-------------+----------------------+-------------------+ > 2 rows in set (0.62 sec) > > Notice how the dst field on the second line is missing. > > Am I doing something wrong here or this is a bug? >Looks like you're hitting this bug: https://issues.asterisk.org/jira/browse/ASTERISK-24443 -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org