Greyman-- I'm taking this discussion to the list. Folks, what we are talking about here, is me trying to get a grasp around Greyman's (Aaron's) request for a bare-bones CDR generation that describes just total connect time for channels, stripping out all the details. Who cares about xfer, park, hold, etc.? So in the following is our discussion about what *should* be there, and in what form... So, what I'm thinking, is to spec out two CDR generation modes, one detailed one according to the spec I'm working on, and the other mode will follow these lines... On Tue, 2009-01-06 at 10:37 +0000, Grey Man wrote:> On Mon, Jan 5, 2009 at 6:42 PM, Steve Murphy <murf at digium.com> wrote: > > I **think** I have a handle on it... Basically, for each channel > > that did anything, no matter what, you'd like a single CDR > > for that channel that would record the time from when it first > > activated to the time it hung up. I'd have to assume the > > first "answer" time would be recorded in the CDR, in case > > multiple "answer" times might apply (for incoming calls, it > > would be the time the pbx 'answered' the incoming call; > > for outgoing calls it would be the time the other end "answered" > > the call... right? > > Hi murf, > > To my mind only hangups should generate CDRs and nothing else should. > When you say "for each channel that did anything" I'd like a CDR I'm > not to sure about that, if you mean to generate a CDR for every type > of channel that is ever hungup then the answer is yes. If you mean to > generate a CDR on non-hangup channel events then the answer is no.OK> > > so, if A calls B, B parks A, A's park expires, B is rung, > > B answers, B xfers A to C, they hang up, we should have > > a CDR for A's time, with the start time being the time > > the PBX created the channel for A; the answer time would > > be (if A is an incoming call) when the PBX answered the > > incoming call and maybe started giving A the IVR experience, > > and (if A is an extension), when B answered the call. The > > end time would be when A was hung up. > > > > A CDR for B would be generated? with his answer time when > > he picked up the phone to answer the incoming call from A? > > and an end time when he parked A? > > > > Another CDR for B would be produced he answered the callback > > from the PBX for the expired session with A, and end when > > he got hung up xferring the call to C? > > > > Another CDR for C would be produced to record C's conversation > > with A, start when his phone started ringing, answer when he > > answered, and end when he hung up? > > > > Am I on the right track? > > I don't use Parking myself so my understanding may be slightly off but > from what I do understand of Parking the CDRs would not be generated > quite how you describe. The main point is that Parking a call should > not generate a CDR as the Park operation has not necessarily ended a > call.Parking a call will hang you up, in most normal cases. This includes calling the Park() app, bxfer to the parking exten, and using the one-touch parking features. But, if some strange combo of events allows someone to park without a hangup, then I'd agree, no CDR should be generated.> > In your description I think the CDRs should be: > > 1 The call from A to the PBX, start time when B answers, end time when > the A-C call is hungup,Can't do this; it would be inaccurate; start time is when A either picks up the phone (if dahdi exten), or when A submits an invite (if sip exten), or when an incoming call (via sip invite, or dahdi fxo i/f) arrives at the pbx. As to Answers, we have to start getting pedantic; if A is an exten, then the first answer will be when B answers. But if A is an incoming call via, say a dahdi fxo interface, or an incoming sip invite, then an s exten is going to get run, and usually the PBX runs the answer() app, and this will usually be the first answer. Now, I can use heuristics to override this first answer if a dial occurs, but... if multiple dials occur, this heuristic would tend to record the last answer; if we override only Answer() in the 's' exten, then we would only record the first answer... is this more like it? Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override an ANSWER on exten s, BTW... And, would it be proper to include all dial attempts? My guess is that you would *NOT* want to see any dial attempts in this mode. Well, at least, in this particular case, if A *tries* to dial B, but B doesn't answer, then since A is a live channel, we would record it's life in the system. When A hangs up, we would see the NO ANSWER disposition, and the destination of B, right? If A tried to dial a group, and nobody answered, the destination would be a random member of that group, the args to the Dial command would record the other members, usually.> > 2. The call from the PBX to B, start time when B answers, end time > when the call to B is hungup once the blind transfer of A to C is > initiated,The start time will be when B is first dialed; The answer time when he answers. I notice that you group the two B CDRs I described into a single entity, but in doing so, you violate your own rule; when B parked A, B was hung up. (He could easily dialed party D, eg, and had a conversation and hung up while A was parked!) According to the rules, there should be two CDR's for B, right?> 3. The call from the PBX to C, start time when C answers Am end time > when the A-C call is hungup. > > I think the main difference in our approaches is that to me the PBX, > in this case Asterisk, should be considered a black box as far as the > CDRs are concerned. Things like parking, holding, re-inviting to > change codecs, etc. etc. are all irrelevant events as far as a CDR is > concerned. The only events of relevance are when the calls to and from > end points external to the PBX are answered and hungup.OK, gotcha. Now, let's talk about the fields in current/future CDRs, and see which you consider relevant? accountcode (user modifiable) amaflags (user modifiable) clid (user modifiable) userfield (user modifiable) --- These 4 fields are set on the channel, and CEL events will record snapshots of these with each channel event. The accountcode can be set to some default value in most channel config files, so it has some value the moment the channel is created. The user can modify these channel values with the CHANNEL() func from the dialplan, as in (eg): Set(CHANNEL(accountcode)=someval) I propose that the last non-null value be used, from the time-sorted list of channel events. It *is* possible (or could be possible), that these fields could be lost... or be reset to the default... answer (timeval) --- see previous discussion... This will probably be the most complicated field to track. And it's not *that* complicated... axfer2hungup (new) --- useless billsec --- the usual (end-time minus answer-time) channel --- the channel name. Pretty basic. Will most likely look like: Dahdi/1-1 Don't be shocked if you see Dahdi/1-2 --it happens with local channels. Don't be shocked if you see Dahdi/1-1<ZOMBIE> -- it happens with masquerading. confid --- useless dcontext --- Since a channel could be connected to several other channels during its lifetime, these fields might be useless. I could set them to the successful first target of a dial attempt... and leave them blank otherwise? If you really need/care about these fields, then maybe this mode is not proper for you. You can use linkedid to find all the other channels that may have conversed with this one. disposition --- See above discussion. dst dstchannel --- Since a channel could be connected to several other channels during its lifetime, these fields might be useless. I could set them to the successful first target of a dial attempt... and leave them blank otherwise? If you really need/care about these fields, then maybe this mode is not proper for you. You can use linkedid to find all the other channels that may have conversed with this one. duration --- the usual (end-time minus start-time) end (timeval) -- the time of the final hangup. lastapp lastdata --- since several dial attempts may be run during the life a channel, in this mode, these fields may not be useful. linkedid (new, sort of) --- very easily could tie different channels together involved in xfers, direct dials, etc. Virally spread from channel to channel as they interact, oldest linkedid wins. There have been fairly extensive discussion on this field. We can append a long uuid system-wide-unique string on a per-linkedID basis, or on a per-asterisk run, or on a per-CDR module load basis, or we simply have an option to add the system name (or whatever string you wish) to the end to allow guaranteed- unique linkedid's across systems. parkingstall (new) --- useless peeraccount --- useless party (new) --- useless src --- what do you *want* this to specify? start (timeval) --- the time the channel was created (activated, whatever). type (new) --- in this mode, this field could be blank or something like "SIMPLE". uniqueid --- useless vars (a list of attached vars) --- right now, CEL doesn't carry these channel vars forward; you'll have to cram them in the userfield string. What I really need to do is describe each field in a/the spec, and when in this simplified mode, what each field records, where and when it gets its data, and what that data means. This might seem a bit tedious, but it's a critical part of the spec, and gets really critical when users don't get what they expect. murf PS, I've updated the CDRfix2 document over the past few weeks... mostly small tweaks, but I did add stuff where a dial operation will split out a new CDR field (in the other mode), forming the PREDIAL type CDR.> Regards, > > Aaron-- Steve Murphy <murf at digium.com> Digium -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3227 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20090106/e9a0a1dc/attachment.bin
Steve Murphy wrote:> So, what I'm thinking, is to spec out two CDR generation modes, > one detailed one according to the spec I'm working on, and the > other mode will follow these lines...Hmmm... I'm liking this idea so far.> On Tue, 2009-01-06 at 10:37 +0000, Grey Man wrote: >>> so, if A calls B, B parks A,CDR generated (hangup event due to attd-xfer)>>> A's park expires, B is rung, >>> B answers, B xfers A to C, they hang up,CDR generated (hangup event)>>> we should have >>> a CDR for A's time, with the start time being the time >>> the PBX created the channel for A; the answer time would >>> be (if A is an incoming call) when the PBX answered the >>> incoming call and maybe started giving A the IVR experience, >>> and (if A is an extension), when B answered the call. The >>> end time would be when A was hung up.In the above scenario, would there be a CDR for when B was called (start time when B answers, or some other event in the dialplan that causes an answer, i.e. Answer(), Playback(), etc...), and then and then hungup? The hangup would be when B attd-xfer A to the parking lot, and B was then hung up.>>> >>> A CDR for B would be generated? with his answer time when >>> he picked up the phone to answer the incoming call from A? >>> and an end time when he parked A?Aha... it seems we agree :)>>> Another CDR for B would be produced he answered the callback >>> from the PBX for the expired session with A, and end when >>> he got hung up xferring the call to C?Agreed.>>> Another CDR for C would be produced to record C's conversation >>> with A, start when his phone started ringing, answer when he >>> answered, and end when he hung up?Also agreed.>>> Am I on the right track?Based on the premise that a CDR would be generated whenever a channel was hung up, then yes, it appears I'm in agreement with you.>> I don't use Parking myself so my understanding may be slightly off but >> from what I do understand of Parking the CDRs would not be generated >> quite how you describe. The main point is that Parking a call should >> not generate a CDR as the Park operation has not necessarily ended a >> call. > > Parking a call will hang you up, in most normal cases. This includes > calling the Park() app, bxfer to the parking exten, and using the > one-touch parking features. But, if some strange combo of events > allows someone to park without a hangup, then I'd agree, no CDR > should be generated.I'm in agreement with how Murf has described the above scenario. If you're going to "keep it simple(tm)" and generate a CDR whenever a channel is hung up, then what Murf has outlined would generate the CDRs as described.>> In your description I think the CDRs should be: >> >> 1 The call from A to the PBX, start time when B answers, end time when >> the A-C call is hungup, > > Can't do this; it would be inaccurate; start time is when A either > picks up the phone (if dahdi exten), or when A submits an invite > (if sip exten), or when an incoming call (via sip invite, or dahdi > fxo i/f) arrives at the pbx.If at all possible, it would be nice if you could build the A-C hangup time, i.e. when call enters the PBX, and when the call is disconnected from the PBX. Ideally you could get a less fine grained picture of a single channels life in the PBX, time-wise.> As to Answers, we have to start getting pedantic; if A is an exten, > then the first answer will be when B answers. But if A is an incoming > call via, say a dahdi fxo interface, or an incoming sip invite, then > an s exten is going to get run, and usually the PBX runs the answer() > app(or a Background(silence/1&...) or Playback(silence/1&...) which would also answer the channel)> and this will usually be the first answer. Now, I can use heuristics > to override this first answer if a dial occurs, but... if multiple dials > occur, this heuristic would tend to record the last answer; if we > override only Answer() in the 's' exten, then we would only record > the first answer... is this more like it?Simple CDRs should be as simple as possible. No heuristics should be done automatically. Perhaps there would be enough information in the CDRs to do this after the fact?> Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override > an ANSWER on exten s, BTW... > > And, would it be proper to include all dial attempts? My guess is > that you would *NOT* want to see any dial attempts in this mode. Well, > at least, in this particular case, if A *tries* to dial B, but B > doesn't answer, then since A is a live channel, we would record > it's life in the system. When A hangs up, we would see the NO ANSWER > disposition, and the destination of B, right? If A tried to dial a > group, and nobody answered, the destination would be a random member > of that group, the args to the Dial command would record the other > members, usually.I'm in agreement with this. A is a live channel. It was processed (I specifically don't say 'answered' here), and then terminated. The disposition should tell me something about the attempted call, which you have outlined. Perhaps we don't want to use the words "Answered" and "Hungup" here. Maybe a better description of a CDR generate is when a 'channel' is 'processed' and 'terminated' instead. The disposition would tell us whether it was answered or not.>> 2. The call from the PBX to B, start time when B answers, end time >> when the call to B is hungup once the blind transfer of A to C is >> initiated, > > The start time will be when B is first dialed; The answer time when > he answers. > > I notice that you group the two B CDRs I described into a single > entity, but in doing so, you violate your own rule; when B parked > A, B was hung up. (He could easily dialed party D, eg, and had a > conversation and hung up while A was parked!) According to the > rules, there should be two CDR's for B, right?I'm pretty sure I'm in agreement with Murf here with how the CDRs should be generated in this scenario.>> 3. The call from the PBX to C, start time when C answers Am end time >> when the A-C call is hungup. >> >> I think the main difference in our approaches is that to me the PBX, >> in this case Asterisk, should be considered a black box as far as the >> CDRs are concerned. Things like parking, holding, re-inviting to >> change codecs, etc. etc. are all irrelevant events as far as a CDR is >> concerned. The only events of relevance are when the calls to and from >> end points external to the PBX are answered and hungup.Based on this paragraph, is seems Aaron would expect a single CDR for call coming into Asterisk (A), and a single CDR to be generated when A is then hung up. (Excuse me if I have over simplified your thoughts.) However, based on the way I know Asterisk works with channels, I would expect 2 CDRs to be generated for every call between end points (when A calls B). This is because there is a channel from A to Asterisk (CDR) and from Asterisk to B (CDR). I do have to agree that being able to get a picture of the A --> Termination as a 'single record' could make the CDRs a bit simpler, but I think that approach needs to be based on some sort of unique tag that would follow channel A around the PBX. I think Murf has mentioned some things can happen to cause that channel to go away, and to not allow that unique identifier to persist in all situations, however the specifics of why and how that happens are hazy at best. Those are at least a few of my thoughts from a third party observer :) Leif Madsen. http://www.leifmadsen.com http://www.asteriskdocs.org
On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy <murf at digium.com> wrote:> > Can't do this; it would be inaccurate; start time is when A either > picks up the phone (if dahdi exten), or when A submits an invite > (if sip exten), or when an incoming call (via sip invite, or dahdi > fxo i/f) arrives at the pbx.I understand what you are saying about start time and I think your approach is correct. I was a bit loose in the use of start and answer time but I agree with you. The answer time is absolutely critical but start time is also required as it can be used for things like identifying how long a user waited for a call to answer.> As to Answers, we have to start getting pedantic; if A is an exten, > then the first answer will be when B answers. But if A is an incoming > call via, say a dahdi fxo interface, or an incoming sip invite, then > an s exten is going to get run, and usually the PBX runs the answer() > app, and this will usually be the first answer. Now, I can use heuristics > to override this first answer if a dial occurs, but... if multiple dials > occur, this heuristic would tend to record the last answer; if we > override only Answer() in the 's' exten, then we would only record > the first answer... is this more like it?That sounds a bit dangerous to me. If you go down the path of setting the answer time based on dial plan applications or events you'll need to understand and modify every dial plan application that can answer a call. To me it would seem a lot simpler to do the override/modification in each channel or even better even lower in ast_channel. A channel has to have a very clearly defined definition of answer and hangup whereas dial plan applications don't.> Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override > an ANSWER on exten s, BTW... > > And, would it be proper to include all dial attempts? My guess is > that you would *NOT* want to see any dial attempts in this mode. Well, > at least, in this particular case, if A *tries* to dial B, but B > doesn't answer, then since A is a live channel, we would record > it's life in the system. When A hangs up, we would see the NO ANSWER > disposition, and the destination of B, right? If A tried to dial a > group, and nobody answered, the destination would be a random member > of that group, the args to the Dial command would record the other > members, usually.I liked you previous approach where all call attempts were recorded and there was a config option to opt out of CDRs for non-answered calls for people that didn't want them. When the Dial command specifies multiple destinations then there should be one CDR for each destination that is dialled irrespective of whether it is answered or not. A disposition of something like CANCELLED could be set for the dial legs that Asterisk cancels after the first one is answered. As an example consider the standard call scenario where a user calls into Asterisk and the dialplan forwards the call to 3 destinations: User A --> Asterisk: Dial(SIP/x&SIP/y&SIP/z) --> SIP/y answers That should generate 4 CDRs: 1. A to Asterisk which is answered, 2. Asterisk to X which is cancelled, 3. Asterisk to Y which is answered, 4. Asterisk ti Z which is cancelled. For people setting the no unanswered call CDRs the 2 and 4th CDRs would not be generated.> I notice that you group the two B CDRs I described into a single > entity, but in doing so, you violate your own rule; when B parked > A, B was hung up. (He could easily dialed party D, eg, and had a > conversation and hung up while A was parked!) According to the > rules, there should be two CDR's for B, right?I think this was just me not being that familiar with parking. If the example had been a transfer I would have been on the ball :-).> OK, gotcha. Now, let's talk about the fields in current/future CDRs, > and see which you consider relevant?The core fields I would put into the Asterisk CDRs are: - uniqueid: A GUID/UUID that cannot be changed and is critical for billing, - calldirection: 0 for a call Asterisk receives and 1 for a call Asterisk initiates, - accountcode (user modifiable) - clid: The channel identifier of the call originator equivalent to the A number on a traditional telco CDR, - dst: The destination of the call equivalent to the B number on a traditional telco CDR, - starttime: The time Asterisk first receives or initiates a call, - progresstime: The time Asterisk first receives or generates a progress indication, - answertime: The time a call is answered, - endtime: The time a call is hungup or cancelled, - duration: endtime - starttime, - billsec: endtime - answertime, - disposition: ANSWERED, TIMEOUT, CANCELLED, HUNGUP and maybe others, - userfield (user modifiable): General purpose field for any custom CDR info needed by Asterisk users. Some extra fields that I think would also be very (if not very very) useful to people: - remoteip: The remote IP address of the call where relevant. For an incoming call the originator's IP address, for an outgoing call the desitanation IP address.Apart from being very useful information it would also be one piece of information useulf in identifying brute force or DoS attacks, - linkedid: Where there is a logical link between different calls such as an incoming call generating an outgoing call this field could be a common UUID/GUID.This field is not as important as the core ones so if there are situations where it becomes ambiguous or doesn't make sense it could be ignored, - channel: The data that was passed to the channel driver for a call. Regards, Greyman.
The continuing discussion on a future "Simple CDR" mode of generation... from which I will extract the info and add a section to the overall CDR spec I'm developing... For newcomers, "Simple CDR" mode would not break the conversations into legs at all. Each CDR would simply record the total time spent alive. It would start when the channel got created. It would end, and the CDR get posted, when the channel got hung up and destroyed. It might have been transferred, parked, put on hold a hundred times in the process, but this wouldn't matter. It's all in the CDR fields, now, really, as the conversation continues... On Wed, 2009-01-07 at 02:56 +0000, Grey Man wrote:> On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy <murf at digium.com> wrote: > > As to Answers, we have to start getting pedantic; if A is an exten, > > then the first answer will be when B answers. But if A is an incoming > > call via, say a dahdi fxo interface, or an incoming sip invite, then > > an s exten is going to get run, and usually the PBX runs the answer() > > app, and this will usually be the first answer. Now, I can use heuristics > > to override this first answer if a dial occurs, but... if multiple dials > > occur, this heuristic would tend to record the last answer; if we > > override only Answer() in the 's' exten, then we would only record > > the first answer... is this more like it? > > That sounds a bit dangerous to me. If you go down the path of setting > the answer time based on dial plan applications or events you'll need > to understand and modify every dial plan application that can answer a > call. To me it would seem a lot simpler to do the > override/modification in each channel or even better even lower in > ast_channel. A channel has to have a very clearly defined definition > of answer and hangup whereas dial plan applications don't. >Hadn't thought along that line before: classifying the *kinds* of Answer. But we may not have to bother.... In this mode, a single CDR could cover several dial attempts and their corresponding "answers".... incoming caller A could, during his lifetime in Asterisk, dial several users, say via assisted xfers, and have the targets hang up first, leaving his channel intact. It doesn't make sense to store an outgoing dial result in the originating channel CDR.... What if, instead, we record the disposition of the dial in the created channel CDR? A channel comes into existence only once. For external incoming calls into the PBX, the disposition is pretty uninteresting, because we'd not create the channel if the disposition wasn't ANSWERED... (well, at least in the DAHDI world, maybe not so much in the voip world)... but, once asterisk dials B in A's behalf, we could record all the dialing action in the CDR for B; It's src/dest related fields could record the dial from A to B; the disposition would be FAIL/BUSY/NOANSWER/etc...> > Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override > > an ANSWER on exten s, BTW... > > > > And, would it be proper to include all dial attempts? My guess is > > that you would *NOT* want to see any dial attempts in this mode. Well, > > at least, in this particular case, if A *tries* to dial B, but B > > doesn't answer, then since A is a live channel, we would record > > it's life in the system. When A hangs up, we would see the NO ANSWER > > disposition, and the destination of B, right? If A tried to dial a > > group, and nobody answered, the destination would be a random member > > of that group, the args to the Dial command would record the other > > members, usually. > > I liked you previous approach where all call attempts were recorded > and there was a config option to opt out of CDRs for non-answered > calls for people that didn't want them. When the Dial command > specifies multiple destinations then there should be one CDR for each > destination that is dialled irrespective of whether it is answered or > not. A disposition of something like CANCELLED could be set for the > dial legs that Asterisk cancels after the first one is answered. > > As an example consider the standard call scenario where a user calls > into Asterisk and the dialplan forwards the call to 3 destinations: > > User A --> Asterisk: Dial(SIP/x&SIP/y&SIP/z) --> SIP/y answers > > That should generate 4 CDRs: > > 1. A to Asterisk which is answered, > 2. Asterisk to X which is cancelled, > 3. Asterisk to Y which is answered, > 4. Asterisk ti Z which is cancelled. >I like the CANCELLED idea.... another disposition! OK, if you set the unanswered=yes, like I have it now, you'd see the CDR's with CANCELLED, otherwise, you would only see the... wait... this brings up some pretty tangled issues. If I'm going to explain channel creation for dialing... especially when you dial more than one target at once... Let's say you do your examp, but we add exten dev SIP/w to the list for variety; suppose: W just plain doesn't ANSWER X is offline, so it's FAIL; Y gets answered; Z is busy If you have unanswered = yes, then you'd expect to see: 1. A to Asterisk which is answered (by the dialplan) 2. Asterisk to X which is FAIL 3. Asterisk to Y which is answered, 4. Asterisk to Z which is BUSY 5. Asterisk to W which is cancelled But if you have unanswered = no, then I guess you'd just see: 1. A to Asterisk which is answered (by the dialplan), 2. Asterisk to X which is FAIL 3. Asterisk to Y which is answered, 4. Asterisk to Z which is BUSY or would unanswered = no also suppress #2 and #4? And, if no one answers any call, we'd see (with unanswered = yes) 1. A to Asterisk which is answered (by the dialplan) 2. Asterisk to X which is FAIL 3. Asterisk to Y which is NO ANSWER, 4. Asterisk to Z which is BUSY 5. Asterisk to W which is cancelled and, if unanswered = no, then we get: ? 1. A to Asterisk which is answered (by the dialplan) 2. Asterisk to X which is FAIL 3. Asterisk to Y which is NO ANSWER, 4. Asterisk to Z which is BUSY Since there was no single winner, would we suppress 2,3,and 4 as well as 5? As if no call were made at all? Why are we prejudiced against just CANCELLED? All I know is, if we are going to record NO ANSWER for calls (or want to), then we'd have to report them for all the losers if there is more than one target for the dial... Since incomplete calls (are not)/(may not be) interesting to billing do we just drop everything but ANSWERED when unanswered = no?> > OK, gotcha. Now, let's talk about the fields in current/future CDRs, > > and see which you consider relevant? > > The core fields I would put into the Asterisk CDRs are: > > - uniqueid: A GUID/UUID that cannot be changed and is critical for billing,In my previous message, I proposed that we could add some config options that would define uniqueid/linkedid behavior, let's get explicit: unique_append_ident=<string> The <string> would be appended to the unique id/linked id when it goes "out the door"; This would allow you to tack on a system name or ip or whatever to every uniqueid/linkedid as it goes into the db/log file/whatever; if you had several systems logging to the same db, you could guarantee that the id's were unique across systems that way. unique_append_uuid = yes would append the uuid (all 36 bytes of it) to the uniqueID/linkedid. This uuid is calculated once per Asterisk invocation; unique_append_uuid = per_channel would append the uuid (all 36 bytes of it) to the uniqueID/linkedid. This uuid is calculated once per channel created. Will this suffice?> - calldirection: 0 for a call Asterisk receives and 1 for a call > Asterisk initiates,Interesting. How exactly do we calculate this? How do we tell an incoming FXO call from an incoming FXS call? The FXS lines will get special attention from asterisk; dialtone is generated, we are waiting for an extension in the dialplan. FXO calls start at the 's' extension... the channel driver, I guess, knows the diff... but higher up? And I've been reminded that the FXO isn't automatically mean that the call is incoming... and vice-versa, so... this is logic external to CDRs, methinks? As to SIP, I guess anything that's not a SIP peer (via sip.conf) is an incoming call? All the time? Guaranteed?> - accountcode (user modifiable) > - clid: The channel identifier of the call originator equivalent to > the A number on a traditional telco CDR,Actually, the underlying CEL interface will report ANI, DNIS, etc. so all these fields are available. I think it would be wise to report (or at least allow) all these values.> - dst: The destination of the call equivalent to the B number on a > traditional telco CDR,I think this is the destination exten. You might want to add the channel, dstchannel, which record the originator/target device info.> - starttime: The time Asterisk first receives or initiates a call,> - progresstime: The time Asterisk first receives or generates a > progress indication,This is useful? I'd have to add this every driver; some may not provide it (maybe)... this is pretty deep-down stuff. How is it useful?> - answertime: The time a call is answered, > - endtime: The time a call is hungup or cancelled, > - duration: endtime - starttime, > - billsec: endtime - answertime, > - disposition: ANSWERED, TIMEOUT, CANCELLED, HUNGUP and maybe others,ANSWERED, NO_ANSWER, FAILED, BUSY, CANCELLED I understand, but you'll have to explain HUNGUP... While we are at it, how about hangupcause? Hangup originator?> - userfield (user modifiable): General purpose field for any custom > CDR info needed by Asterisk users. > > Some extra fields that I think would also be very (if not very very) > useful to people: > > - remoteip: The remote IP address of the call where relevant. For an > incoming call the originator's IP address, for an outgoing call the > desitanation IP address.Apart from being very useful information it > would also be one piece of information useulf in identifying brute > force or DoS attacks, >This would be good info from the voip related protocols... it seems reasonable to add this, but I kinda wonder how hard this will be to coax from the channel drivers... I have to look and see if this stored on the channel... never played with it before.> - linkedid: Where there is a logical link between different calls such > as an incoming call generating an outgoing call this field could be a > common UUID/GUID.This field is not as important as the core ones so if > there are situations where it becomes ambiguous or doesn't make sense > it could be ignored, > > - channel: The data that was passed to the channel driver for a call.you probably mean the lastapp/lastdata fields here. I think we may need to look at these fields a little closer. There are several places in the code where a dial-type-operation is performed, but the Dial() app is not called to do it... followme, queues, call files, ami originate, places like that. It might be good to have the method of making the call recorded in the CDR in the lastapp field; like queue#Dial park#Dial, CallFile#Dial, etc. Also, you left out the "party" field... If A calls in, and dials B, (well, asterisk dials B in A's behalf), and B xfers A to C, then, wouldn't you be at all interested in the fact, that even tho B called C, it was A that spent all the time on the line? Eh, I guess it wouldn't really matter, would it? If C was in Namibia, would B always be billed for the call, or would anyone ever be tempted to bill A's dept for that call? (Assuming, I guess, that A & B are both internal)... murf> > Regards, > > Greyman.-- Steve Murphy <murf at digium.com> Digium -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3227 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20090107/69e0c82f/attachment.bin
On Thu, Jan 8, 2009 at 7:34 PM, Leif Madsen <leif.madsen at asteriskdocs.org> wrote:> My apologies. I had installed a tool for posting Asterisk releases, and > forgot to turn off all the automatic stuff. This was a reply that > reflects my personal opinions on the matter, not all of the Asterisk > Development Team.Pity, I thought Asterisk had become sentinent ;-). It would have made bug fixing a lot easier. The new Rule The World feature might have been an issue though... Regards, Greyman.
> I may be over simplifying but I would have a serial number object that > gets incremented anytime it is called and will be set to 0 at start-up. > I would then use it to generate a UUID like this: > MAC.serialid.64bit timedateI suggest reviewing RFC 4122, which discusses UUID formats in some detail. Your suggestion is very close to a standard "version 1" UUID, which includes the host's MAC address, 60 bits of time information, and a 14-bit "clock sequence value" (which is set randomly at startup, and incremented if the system clock value is adjusted forwards or backwards or if the node ID changes). The time value has a 100-nanosecond resolution, which sets a lower limit to the amount of time which may be allowed to pass between UUID generation events. By my math this field won't wrap until after the year 5,000 C.E., so we have a while to prepare for the "Y5237" wraparound problem :-)