[asterisk-bugs] [JIRA] (ASTERISK-24839) CDRs: LinkedID field in Attended Transfer not reporting as expected

Jonas Swiatek (JIRA) noreply at issues.asterisk.org
Sat Feb 28 12:49:34 CST 2015


     [ https://issues.asterisk.org/jira/browse/ASTERISK-24839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonas Swiatek updated ASTERISK-24839:
-------------------------------------

    Attachment: sip.conf
                extensions.conf
                cdr.conf
                cdr_adaptive_odbc.conf

Configuration files

> CDRs: LinkedID field in Attended Transfer not reporting as expected
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-24839
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24839
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/cdr_adaptive_odbc, CDR/General
>    Affects Versions: 13.2.0
>         Environment: Linux CentOS6 (Amazon Linux on AWS EC2)
>            Reporter: Jonas Swiatek
>            Assignee: Jonas Swiatek
>            Severity: Critical
>         Attachments: cdr_adaptive_odbc.conf, cdr.conf, extensions.conf, sip.conf
>
>
> Initial report made here: http://forums.asterisk.org/viewtopic.php?f=1&t=92599, and malcolmd has directed me to create this issue.
> Asterisk doesn't generate CDR Data it should according to the Asterisk 12 CDR Specification for the "Attended Transfer to Channel"-scenario.
> *\[EDIT\]*: [~mjordan]: I've copied/pasted the actual error from the forums here, as this is the important bit:
> {quote}
> What I get in my CDR records is:
> || seq || src || dst || dcontext || uniqueid || linkedid ||
> | 141 | 682 | 850 | act-22575 | 1424894097.687 | 1424894097.687 | 
> | 143 | 850 | 851 | act-22575 | 1424894105.695 | 1424894105.695 <- notice linkedid different | 
> | 145 | 682 | 850 | act-22575 | 1424894097.687 | 1424894097.687 | 
> What I would expect (according to the Asterisk 12 CDR Spec), is something like this:
>  || seq || src || dst || dcontext || uniqueid || linkedid || 
> | 141 | 682 | 850 | act-22575 | 1424894097.687 | 1424894097.687 | 
> | 143 | 850 | 851 | act-22575 | 1424894105.695 | 1424894097.687 | 
> | 145 | 682 | 851 | act-22575 | 1424894097.687 | 1424894097.687 | 
> {quote}
> I'm using adaptive-odbc, connected to a PostgreSQL Database, with the following configuration:
> {noformat}
> [first]
> connection=asterisk-pgsql
> table=asterisk_cdr
> alias start => calldate
> {noformat}
> {{cdr.conf}} is the default created when running make samples, but set to log both unanswered and congested calls.
> This is my full configuration in extensions.conf:
> {noformat}
> [general]
> static                          = yes
> writeprotect                    = no
> extenpatternmatchnew            = yes           ; Using new pattern matcher as a test
> clearglobalvars                 = no
> userscontext                    = default	; User context is where entries from users.conf are registered.
> [account-shared-extensions-22575]
> exten => 682,1,NoOp()
>         same => n,Set(CDR(userid)=9264)
>         same => n,Set(AccountID=22575)
>         same => n,Dial(SIP/swiatek,25)
>         same => n,Hangup()
> exten => 850,1,NoOp()
>         same => n,Set(CDR(userid)=9574)
>         same => n,Set(AccountID=22575)
>         same => n,Dial(SIP/swiatek2,25)
>         same => n,Hangup()
> exten => 851,1,NoOp()
>         same => n,Set(CDR(userid)=9598)
>         same => n,Set(AccountID=22575)
>         same => n,Dial(SIP/swiatek3,25)
>         same => n,Hangup()
> [user-default-9264] ;swiatek
> include => account-shared-extensions-22575
> exten => *99,1,NoOp()
>         same => n,VoiceMailMain(swiatek at vm-22575,s)
>         same => n,Hangup()
> [user-default-9574] ;swiatek2
> include => account-shared-extensions-22575
> exten => *99,1,NoOp()
>         same => n,VoiceMailMain(swiatek2 at vm-22575,s)
>         same => n,Hangup()
> [user-default-9598] ;swiatek3
> include => account-shared-extensions-22575
> exten => *99,1,NoOp()
>         same => n,VoiceMailMain(swiatek3 at vm-22575,s)
>         same => n,Hangup()
> {noformat}
> This is my users configured at the end of sip.conf (rest of the file is unchanged except for allowing some IP ranges):
> {noformat}
> [user-template](!)
> type            = friend
> host            = dynamic
> dtmfmode        = auto
> disallow        = all
> allow           = ulaw
> allow           = alaw
> ;secret         = testhest
> context         = outbound-init
> mohsuggest	= sound_1
> alwaysauthreject=yes
> [swiatek](user-template)
> context=user-default-9264
> callerid="Jonas Swiatek" <682>
> mailbox=swiatek at vm-22575
> accountcode=22575
> mohsuggest=sound_1
> [swiatek2](user-template)
> context=user-default-9574
> callerid="Jonas 2" <850>
> mailbox=swiatek2 at vm-22575
> accountcode=22575
> [swiatek3](user-template)
> context=user-default-9598
> callerid="Jonas 3" <851>
> mailbox=swiatek3 at vm-22575
> accountcode=22575
> {noformat}
> Steps taken:
> When testing this, I've got three phones (A(682), B(850) and C(851)) on my desk, one for each extension. I test is like this:
> # A, dial B
> # Pickup B, press Transfer, dial 851#
> # Pickip C, hangup B. C and A are connected.
> # Hangup A.
> See the initial post (http://forums.asterisk.org/viewtopic.php?f=1&t=92599) for a formatted layout of the table data I'm getting, and what I think it should be when reading the CDR Spec for Asterisk 12 and later.
> Recording log output from Asterisk during this test call:
> {noformat}
>   == Using SIP RTP CoS mark 5
>     -- Executing [850 at user-default-9264:1] NoOp("SIP/swiatek-00000032", "") in new stack
>     -- Executing [850 at user-default-9264:2] Set("SIP/swiatek-00000032", "CDR(userid)=9574") in new stack
>     -- Executing [850 at user-default-9264:3] Set("SIP/swiatek-00000032", "AccountID=22575") in new stack
>     -- Executing [850 at user-default-9264:4] Dial("SIP/swiatek-00000032", "SIP/swiatek2,25") in new stack
>   == Using SIP RTP CoS mark 5
>     -- Called SIP/swiatek2
>     -- SIP/swiatek2-00000033 is ringing
>     -- SIP/swiatek2-00000033 answered SIP/swiatek-00000032
>     -- Channel SIP/swiatek-00000032 joined 'simple_bridge' basic-bridge <7910e64c-3f55-4153-b591-e092f1f61172>
>     -- Channel SIP/swiatek2-00000033 joined 'simple_bridge' basic-bridge <7910e64c-3f55-4153-b591-e092f1f61172>
>     -- Channel SIP/swiatek2-00000033 left 'native_rtp' basic-bridge <7910e64c-3f55-4153-b591-e092f1f61172>
>     -- Channel SIP/swiatek-00000032 left 'native_rtp' basic-bridge <7910e64c-3f55-4153-b591-e092f1f61172>
>   == Spawn extension (user-default-9264, 850, 4) exited non-zero on 'SIP/swiatek-00000032'
>   == Using SIP RTP CoS mark 5
>     -- Executing [850 at user-default-9264:1] NoOp("SIP/swiatek-00000034", "") in new stack
>     -- Executing [850 at user-default-9264:2] Set("SIP/swiatek-00000034", "CDR(userid)=9574") in new stack
>     -- Executing [850 at user-default-9264:3] Set("SIP/swiatek-00000034", "AccountID=22575") in new stack
>     -- Executing [850 at user-default-9264:4] Dial("SIP/swiatek-00000034", "SIP/swiatek2,25") in new stack
>   == Using SIP RTP CoS mark 5
>     -- Called SIP/swiatek2
>     -- SIP/swiatek2-00000035 is ringing
>     -- SIP/swiatek2-00000035 answered SIP/swiatek-00000034
>     -- Channel SIP/swiatek-00000034 joined 'simple_bridge' basic-bridge <8d1a7359-cda4-4b00-bd99-16227d0c05f8>
>     -- Channel SIP/swiatek2-00000035 joined 'simple_bridge' basic-bridge <8d1a7359-cda4-4b00-bd99-16227d0c05f8>
>     -- Music class sound_1 requested but no musiconhold loaded.
>   == Using SIP RTP CoS mark 5
>     -- Executing [851 at user-default-9574:1] NoOp("SIP/swiatek2-00000036", "") in new stack
>     -- Executing [851 at user-default-9574:2] Set("SIP/swiatek2-00000036", "CDR(userid)=9598") in new stack
>     -- Executing [851 at user-default-9574:3] Set("SIP/swiatek2-00000036", "AccountID=22575") in new stack
>     -- Executing [851 at user-default-9574:4] Dial("SIP/swiatek2-00000036", "SIP/swiatek3,25") in new stack
>   == Using SIP RTP CoS mark 5
>     -- Called SIP/swiatek3
>     -- SIP/swiatek3-00000037 is ringing
>     -- SIP/swiatek3-00000037 answered SIP/swiatek2-00000036
>     -- Channel SIP/swiatek2-00000036 joined 'simple_bridge' basic-bridge <2078600c-dd52-4005-8d67-4963b8b3dcf2>
>     -- Channel SIP/swiatek3-00000037 joined 'simple_bridge' basic-bridge <2078600c-dd52-4005-8d67-4963b8b3dcf2>
>     -- Channel SIP/swiatek-00000034 left 'native_rtp' basic-bridge <8d1a7359-cda4-4b00-bd99-16227d0c05f8>
>     -- Channel SIP/swiatek2-00000036 left 'native_rtp' basic-bridge <2078600c-dd52-4005-8d67-4963b8b3dcf2>
>     -- Channel SIP/swiatek-00000034 swapped with SIP/swiatek2-00000036 into 'native_rtp' basic-bridge <2078600c-dd52-4005-8d67-4963b8b3dcf2>
>   == Spawn extension (user-default-9574, 851, 4) exited non-zero on 'SIP/swiatek2-00000036'
>     -- Channel SIP/swiatek2-00000035 left 'simple_bridge' basic-bridge <8d1a7359-cda4-4b00-bd99-16227d0c05f8>
>     -- Channel SIP/swiatek3-00000037 left 'native_rtp' basic-bridge <2078600c-dd52-4005-8d67-4963b8b3dcf2>
>     -- Channel SIP/swiatek-00000034 left 'native_rtp' basic-bridge <2078600c-dd52-4005-8d67-4963b8b3dcf2>
>   == Spawn extension (user-default-9264, 850, 4) exited non-zero on 'SIP/swiatek-00000034'
> {noformat}



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



More information about the asterisk-bugs mailing list