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

Wed Jul 18 09:47:36 CDT 2012

On Wed, 2012-07-18 at 09:16 -0500, Matthew Jordan wrote:
> 
> ----- 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".

That makes sense to me

> 
> <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.

Fair enough, now that I know why it behaves as it does, I can go about
making it behave the way I want it to.

Your answers have been very helpful and I really appreciate it.

> 
> > 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
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
Ishfaq Malik <ish at pack-net.co.uk>
Department: VOIP Support
Company: Packnet Limited
t: +44 (0)845 004 4994
f: +44 (0)161 660 9825
e: ish at pack-net.co.uk
w: http://www.pack-net.co.uk

Registered Address: PACKNET LIMITED, 2A ENTERPRISE HOUSE, LLOYD STREET
NORTH, MANCHESTER
SCIENCE PARK, MANCHESTER, M156SE
COMPANY REG NO. 04920552