[asterisk-bugs] [JIRA] (ASTERISK-21394) [patch] - Fundamental changes to CDR within single asterisk family (1.8) during externally initiated blind transfers with an h extension present
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Mon Apr 29 09:35:39 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-21394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205960#comment-205960 ]
Matt Jordan commented on ASTERISK-21394:
----------------------------------------
{quote}
1. Call inbound arriving from external trunk rings ext 6000
2. 6000 answers
3. 6000 does SIP blind transfer to the external trunk with dial plan 8001 to ring a remote device.
Mixmonitor is used to record the call
Results:
1. Steps 2 and 3 both get logged by CDR with the same unique ID
2. Step 3 gets saved with internal call direction although the call was outgoing
3. Mixmonitor saves the same playback results to both call legs (presumably because the call legs have the same unique ID).
I'll attach a pdf showing the results in a reporting summary
I'll attach a verbose debug log with SIP debugging and the CDR record
{quote}
This isn't the issue that the reporter was facing. I mentioned on ASTERISK-21486 that it would be worth testing this patch, but it sounds as if it doesn't resolve your issue.
A few other notes:
# A unqiue ID is not unique to a CDR. That is a channel unique ID. You can construct a full unique identifier based on the channel unique ID, the CDR sequence number, and - if you really need it - the linkedid.
# Asterisk has no concept of inbound versus outbound, nor will it ever. The concept of an inbound call versus an outbound call has to be performed by the dialplan writer. The fact that your billing system is flagging something as 'incoming' is a problem with your billing system.
Since your issues are not related to this problem, and since it appears as if fixing the issues you are facing would require fundamental changes in the behavior of Asterisk's CDRs, it does not appear as if there is anything else required on this issue.
> [patch] - Fundamental changes to CDR within single asterisk family (1.8) during externally initiated blind transfers with an h extension present
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-21394
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-21394
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: CDR/General
> Affects Versions: 1.8.18.0, 1.8.20.0, 1.8.21.0
> Environment: Centos 5
> Reporter: Ishfaq Malik
> Assignee: Matt Jordan
> Attachments: Basic SIP blind transfer debug with patch test results.txt, fix_missing_blindXfer_cdr, fix_missing_blindXfer_cdr2, Master(with patch).csv, queue cdr with patch.rar, Two recordings are identical in playback and bad call direction.pdf
>
>
> The way that asterisk handles the CDR for blind transfers has changed between version 1.8.7.0 and 1.8.18.0. The call path is: inbound call from SIP provider -> asterisk server -> SIP peer -> transfer to another SIP Peer. The transfer is done by using the dedicated keys on the hardware and not the features.conf method.
> In version 1.8.7.0 this would produce 2 entries in the CDR, 1 showing the time the inbound call started and which context it was handles by, the second showing the the context the peer belongs to and looking like an extension to extension call.
> We tried upgrading to 1.8.18.0 and did some regression testing and found that the CDR now only produces a single entry with the details all pertaining to the second leg of the call (bar the duration which is for the full life of the call). It has no reference to the inbound context that initially handled the call.
> This is a pretty big change to be inside a single branch and I'm guessing it wasn't intentional.
> Also, all our servers are installed using Puppet so the configuration on them all is the same and we use RealTime Architecture from a single database.
> Here is an example (with sanitised data):
> Here is how an inbound blind transferred call is recorded in 1.8.7.0
> {noformat}
> *************************** 1. row ***************************
> calldate: 2013-04-04 11:42:09
> clid:
> src: <my-mobile>
> dst: s
> dcontext: <inbound-number-context>
> channel: SIP/xxx.xxx.xxx.xxx-00002ba3
> dstchannel: SIP/501-00002ba7
> lastapp: Dial
> lastdata: SIP/501&SIP/511&SIP/531,10
> duration: 22
> billsec: 12
> disposition: ANSWERED
> amaflags: 3
> accountcode:
> userfield:
> *************************** 2. row ***************************
> calldate: 2013-04-04 11:42:31
> clid:
> src: <my-mobile>
> dst: 504
> dcontext: <peer-context>
> channel: SIP/xxx.xxx.xxx.xxx-00002ba3
> dstchannel: SIP/504-00002bbb
> lastapp: Dial
> lastdata: SIP/504,20
> duration: 7
> billsec: 5
> disposition: ANSWERED
> amaflags: 3
> accountcode:
> userfield:
> 2 rows in set (0.03 sec)
> {noformat}
> And here is how it is recorded in 1.8.18.0
> {noformat}
> *************************** 1. row ***************************
> calldate: 2013-04-04 11:39:24
> clid:
> src: <my-mobile>
> dst: 503
> dcontext: <peer-context>
> channel: SIP/xxx.xxx.xxx.xxx-000000ea
> dstchannel: SIP/503-000000ed
> lastapp: Dial
> lastdata: SIP/503,20
> duration: 34
> billsec: 9
> disposition: ANSWERED
> amaflags: 3
> accountcode:
> userfield:
> {noformat}
> In the newer version there is only one entry which has the combined call
> time in it but the dcontext corresponds with the second leg of the call
> which means we can't see what number was dialled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list