----- Original Message ----- > From: "Ishfaq Malik" <i...@pack-net.co.uk> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" > <asterisk-users@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 -- _____________________________________________________________________ -- 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