[asterisk-users] Inconsistency in CDR between NO ANSWER and BUSY calls

[Matthew Jordan]

----- Original Message -----
> From: "Ishfaq Malik" <ish at pack-net.co.uk>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com>
> Sent: Wednesday, July 18, 2012 3:13:13 AM
> Subject: Re: [asterisk-users] Inconsistency in CDR between NO ANSWER and BUSY calls
> 
> On Wed, 2012-07-11 at 15:08 +0100, Ishfaq Malik wrote:
> > Hi
> > 
> > I'm using asterisk 1.8.7
> > 
> > My dialplan for an inbound number is along the lines of
> > 
> > [default]
> > exten => idenfier,1,Goto(specific-context,s,1)
> > 
> > [specific-context]
> > exten => s,1,NoOp()
> > exten => s,2,Dial(SIP/some-extenion,20)

<snip>

So, I mocked up what is essentially the same scenario using the following
dialplan:

[default]
exten => 100,1,NoOp()
same => n,Goto(new_context,s,1)

[new_context]
exten => s,1,NoOp()
same => n,Dial(SIP/phone_b,10)

Assume that I have two SIP peers, phone_a and phone_b, where phone_a dials
extension 100 in context default.

In my case, I had phone_a first call phone_b, and did not answer with phone_b.
That resulted in a disposition of NOANSWER.  I then had phone_a call phone_b
and had phone_b explicitly reject phone_a's call; that resulted in a disposition
of BUSY.

In that case, with the csv and csv-custom CDR backends, I get the following CDR
records:

[csv]

"","phone_a","100","default","""phone_a"" <phone_a>","SIP/phone_a-00000000","SIP/phone_b-00000001","Dial","SIP/phone_b,10","2012-07-18 13:52:50",,"2012-07-18 13:53:00",10,0,"NO ANSWER","DOCUMENTATION","1342619570.0",""
"","phone_a","100","default","""phone_a"" <phone_a>","SIP/phone_a-00000002","SIP/phone_b-00000003","Dial","SIP/phone_b,10","2012-07-18 13:53:10",,"2012-07-18 13:53:16",6,0,"BUSY","DOCUMENTATION","1342619590.2",""

[csv-custom]

"""phone_a"" <phone_a>","phone_a","100","default","SIP/phone_a-00000000","SIP/phone_b-00000001","Dial","SIP/phone_b,10","2012-07-18 08:52:50","","2012-07-18 08:53:00","10","0","NO ANSWER","DOCUMENTATION","","1342619570.0","",0
"""phone_a"" <phone_a>","phone_a","100","default","SIP/phone_a-00000002","SIP/phone_b-00000003","Dial","SIP/phone_b,10","2012-07-18 08:53:10","","2012-07-18 08:53:16","6","0","BUSY","DOCUMENTATION","","1342619590.2","",2

You'll note that in both, the destination context is "default".  So at the very
least, the records are consistent.

I ran this test using the latest from 1.8 (1.8.15.0-rc1) - since the version
you're using is older and 1.8 has had some bug fixes with respect to CDRs
since then, that might explain the discrepancy.

Why is destination context "default" and not "new_context"?  The destination context
is initially set when the CDR for the call is initialized - in which case, its initial
value is "default", since that's where the call entered.  When a CDR is updated, the
destination context is also updated to the channel's current context (or macrocontext).
As it is, a CDR update is not the same thing as the CDR being ended, and does not always
occur before the CDR is ended.  In the case you've outlined, an explicit CDR update
does not occur before the CDR record is ended - which results in the original context
of default being recorded as opposed to the current context of the channel, "new_context".

<snip>

> > Has anyone else experienced this? Is it actually correct behaviour
> > and
> > if so, why? If it is a bug, has it already been raised?

A quick search through JIRA would answer this question.  I don't believe anyone has
filed a bug related to this issue.

As far as it being the correct behavior - the behavior of the destination context
feels more implied then well defined.  Currently, the destination context is updated
when the source and destination channels are bridged, as opposed to when the Dial
is executed to the destination channel.  If the bridge never occurs, then the
destination context is the original context of the source channel, since that's the
most information that is known at the time of CDR creation.  While that behavior
may not be what you desired, it is at least the current implementation.
 
> > Thanks in advance
> > 
> >  
> > 
> Would I be better off asking this question of the dev community?

Nope, as this isn't an Asterisk development question.

> Thanks
> 
> Ish


--
Matthew Jordan
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org