On Wed, 2012-07-18 at 09:16 -0500, Matthew Jordan wrote: > > ----- 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".
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 <i...@pack-net.co.uk> Department: VOIP Support Company: Packnet Limited t: +44 (0)845 004 4994 f: +44 (0)161 660 9825 e: i...@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 -- _____________________________________________________________________ -- 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