[asterisk-users] CDR dst value null after attended transfer

Matthew Jordan mjordan at digium.com
Thu Mar 26 11:53:19 CDT 2015


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



More information about the asterisk-users mailing list