[asterisk-commits] murf: branch murf/RFCs r159733 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Thu Nov 27 21:59:14 CST 2008
Author: murf
Date: Thu Nov 27 21:59:13 2008
New Revision: 159733
URL: http://svn.digium.com/view/asterisk?view=rev&rev=159733
Log:
Rehash the text for a Leg-based CDR approach; This simplifies the situation a great deal. Forget a mix. Forget the channel CDR approach. This is clearly the way to go.
Modified:
team/murf/RFCs/CDRfix2.rfc.txt
Modified: team/murf/RFCs/CDRfix2.rfc.txt
URL: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=diff&rev=159733&r1=159732&r2=159733
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (original)
+++ team/murf/RFCs/CDRfix2.rfc.txt Thu Nov 27 21:59:13 2008
@@ -1,3 +1,8 @@
+WORK IN PROGRESS: There may blatant falsehoods in this document,
+large gaps, QUESTIONS brought up, things to INVESTIGATE, etc.
+Feel free to send corrections and fill in the gaps!
+
+
My previous idea of moving to a bridge-based CDR has proved over the
last year to be bankrupt. As we go further down that road, the
problems get harder and harder to solve, and we still haven't achieved
@@ -24,157 +29,81 @@
CDR_HANDLING_INLINE option. All current behavior is preserved
by NOT setting this var, which is by default Off.
-Channel Role
-------------
-
-In dial, queue, etc, there is a concept of whether a channel is
-"channel" or "peer". Back in the 1.2 days, "channel" channels got a
-CDR assigned, and peers did not. Pretty much, if a channel had a CDR,
-it got published, and "channel" channels got a pbx assigned. And, when
-a pbx reached the end via hangup, it got its h extension run. Between
-the PBX and dial() this meshed up well enough, because all incoming
-calls would get a PBX associated with it, whether FXS or FXO, and dial
-would fire up the peer channels to make a call. We want a CDR for
-bridged (answered/completed calls), so it worked out well enough.
-
-But then, along came transfers and parks. In general, they work with
-CDRs and h-extens sometimes, and not in others. Here's one case: A
-call B; B puts A in the parking lot; In this sequence of events, A is
-a "channel", and B is a "peer". When B deposits A into parking, B is
-hungup. Because he was a dial peer, he shouldn't get an h-exten run on
-him; and no CDR, either. (but because of the bridging code running its
-own h-exten, one will now.). From here, Different things can happen:
-
-1. A hangs up while parked (the "tired of being parked" case)
-2. The parking lot timer expires, and B is re-dialed and connected
-3. The parking lot timer expires, B is redialed, but does not answer.
-4. Another party, C dials A's parking extension (701, perhaps), and
- connects to A.
-
-In case 1, if A hangs up, it should both get its h-exten run, and a
-CDR generated. There's a little problem here in the existing code. The
-bridge h-exten will run the h-exten if the park masqueraded the
-channel; otherwise it may not.
-
-In case 2, all would seem well. B is again the peer, A resumes its
-position as channel.
-
-In case 3, I'd imagine that this will bring about A's demise, and
-h-exten and CDR generation should be OK.
-
-In case 4, C would play the role of "channel", and get a new PBX
-formed. C would have its own CDR, too. What happens to A's stuff?
-
-I think that the consensus feeling I get about what the community
-would want is that if A calls in, its CDR would not be posted until A
-hung up, no matter how many times A was parked, tranferred to other
-parties, etc, and that CDR would reflect the total time that A lived
-(from the time A called in to the time A hung up). In a way, who is
-indicated as the "destination" of the call is irrelevant, because it
-may have changed several times. On that final CDR, it might be the
-first party dialed, or it might be the last, depending on how things
-are updated. I also get the feeling that further CDR's should be
-emitted for each Xfer, to describe the particulars.
-
-Well, to do this, we are going to have to keep better track of that
-channel/peer status or "Role" as I'm to name it.
-
-So, To follow this line of thought, I'm going to create another
-channel variable, and call it "role", and role can be either
-"Channel", or "Peer", or "Channel-Elect". An integer var, with 3
-integer constants, like CHANNEL_ROLE_CHANNEL, and CHANNEL_ROLE_PEER,
-and CHANNEL_ROLE_CHANNEL_ELECT. The channel creation routine would set
-this to be CHANNEL when a channel is created. The
-dial/queue/Followme/whatever apps that create channels to ring, should
-set the role of those channels to PEER.
-
-CHANGE: add "role" variable to the channel struct.
-
-Here's the rules for Role Manipulation:
-
-1. If you want to connect a Channel to a Peer, or vice versa, no big
- deal, it's OK.
-
-2. If you want to connect a Peer to a Peer, I have no idea what to do
- right now. INVESTIGATE.
-
-3. If you want to connect a Channel to a Channel, then you have a
- problem. One should be 'downgraded' to a peer, the other left as a
- 'Channel'? Or both left in Channel Role?
-
-I tried to imagine a sequence, where two true Channel role channels
-are connected together in a bridge. Let's see... A calls into
-Asterisk. B calls in also. A calls C; B calls D. (They have to call
-SOMEONE). And C can't xfer A to D, D is busy. The only way I can
-think of connecting A to B is via Meetme; and it's clear that Meetme
-is a different animal; all channels being connected via Meetme would
-be of Channel status, each with its own PBX thread running... So, if
-two Channel-role channels are being bridged, one is really a peer.
-
-Since the channel UniqueID's reflect a time and an incrementing
-number, "Age" is probably a relevant factor here; the oldest channel
-wins? Or, should it be that FXO channels will win over FXS? Perhaps,
-we can disambiguate this way: Another Role state:
-Channel-Elect. Incoming calls via FXO interfaces get full CHANNEL
-role. FXS stations, when they go off-hook, get CHANNEL_ELECT
-status. If a CHANNEL_ELECT wants to connect to a CHANNEL, it
-downgrades to PEER. If a CHANNEL_ELECT connects to a PEER, it's
-upgraded to CHANNEL. CHANNEL_ELECT status at hangup time are treated
-like PEER; their CDR's are erased, and not posted. Their h exten is
-not run. An example: a local extension is picked up by a user, who
-changes his mind, and hangs back up. The channel driver knows which
-extens are FXO, and which are FXS, and the state can be set at the
-time that off-hook is detected. Also, for voip protocols like SIP, a
-local exten versus an incoming INVITE should be able to be discerned,
-and the proper Role assigned.
-
-If a CHANNEL_ELECT tries to connect to a CHANNEL, it should have a PBX
-thread associated with it, and a CDR. We can free the CDR and end the
-PBX at this juncture as part of the connect process. The PBX ending
-process should not generate an h-exten call for a channel that is only
-CHANNEL_ELECT.
-
-So, if two CHANNEL role channels are connected, if that's possible, I
-think the proper action is to leave them both in the CHANNEL role. If
-they split again and continue with other actions, they will each
-continue flowing thru their dialplan threads, and each will generate
-their proper CDR.
-
-Hmmmm. Outgoing calls. If A is FXS, and picks up, and dials out thru
-an FXO interface, then it will start out as an CHANNEL_ELECT, and the
-FXO interface will start as a PEER, assigned by Dial. A will be
-upgraded to CHANNEL when B answers.... sounds OK so far... But if A
-parks B, then B, a connection to the outside world, gets stays at
-PEER; If C picks it up, C will be Channel, and B will remain Peer. If
-the telco sends you a bill, you'll see one call from their side; Yet,
-in the CDR's you'll see two from Asterisk; one originating from A, the
-other from B, as if they each separately dialed B. On one hand, this
-might be good, this might be bad. One set of people might say good,
-since A might have called B, but C spent time talking to him, C should
-be billed for the privilege. Another set might differ, pointing out
-that B should be responsible for the entire call. To make B
-responsible for the entire call, dial can pay attention to whether a
-normally peer line is FXO; and if it is, it can leave it as
-"CHANNEL". It can fire up a pbx on that channel (or move it from A to
-B), move the CDR on A from A to B, and set A to PEER. Moreover, it can
-easily only do the above manipulations if a certain config file option
-is set. (Perhaps in cdr.conf).
-
-CHANGE: Add cdr.conf config file option: Outgoing_FXO_Role_Channel or
- something. Forces Asterisk to set FXO lines in CHANNEL role
- when dialed.
-
-GOAL:
-
-If we can properly manipulate the channel roles during the xfer/park
-process, we can simplify the cases we have to study. Rather than
-just leaving the channel roles alone, and trying to handle all
-the possible cases, if we instead reduce the situation back to
-the expected "channel role makes call to peer channel", we can
-simplify the logic considerably.
-
-Am I thinking clearly?
-
+TWO CDR PHILOSOPHIES
+--------------------
+
+There seem to be, in the CDR universe, two different philosophies:
+1. Channel based
+2. Leg based
+
+They can both get the job done, but the kind of issues you have
+with Asterisk varies between them.
+
+In a channel-based sort of system, a CDR stays with a channel until
+it hangs up. Thus, if A calls B, and B transfers A to C, and C
+transfers A to D, a minumum of one CDR would be generated
+for A, starting when it called in or picked up, answered when
+B answered, and ended when A or D hung up. Hopefully, other
+CDRs would be emitted to record the xfer to C and D.
+
+In a leg-based sort of system, CDRs would follow bridging.
+In the previous mentioned sequence, a CDR would be generated
+for the conversation of A and B, another for A and C, and another
+for A and D. To find out how much time A spent total, you would
+have to fetch the start time from the first, and add the other
+times from the other CDRs, or fetch the first and last CDR's
+for the CDR group, and subtract the final ending time from the
+initial start time. In this system, park and hold times could
+also be recorded, but if output, would/could split the CDR's;
+in other words, if C put A on hold for 10 seconds before attempting
+the transfer to B, then there would be a CDR for the A-C conversation,
+another for the hold-time, another for the continued A-C conversation,
+and another for the transfer.
+
+In this specification, we will use the Leg-based system. Asterisk
+was originally set up for a channel-based CDR system, but a few
+complications come with transfers and parks; a major problem
+occurs with masquerading, in that the channel/peer relationships
+get swapped. We will probably not escape having to do a full
+analysis of masquerading and how it affects the channel/peer
+relationships, but that will come later in this spec (timewise).
+
+
+===========
+<I removed the section about Channel/Peer Roles;
+ and a description of masqerading....
+ it looks very much like this approach makes this
+ study uninteresting>
+===========
+
+
+
+==================
+The LinkedID Field
+==================
+
+Asterisk's Trunk version will soon be merged with the goodies in
+newcdr; this includes not only CEL, but also the 'linkedID' stuff.
+LinkedID will be a channel variable, and will be set with the value
+of the uniqueID field when the channel is first created.
+
+The uniqueID is set from the current time in seconds, and a global
+counter. It is set to something like 1227840935.14. This provides
+it's 'age'. When two channels interact, the older (smaller) linkedID
+will overwrite the 'younger' between the two channels. Channels interact
+when they are bridged, etc.
+
+In my examples, I just use something like 'abc123' or suchlike to
+represent the linkedID field.
+
+We set up a config file element to allow you to format the linkedID
+field when it is output to a CDR. While playing with the numeric
+representation is probably not wise, you might find it useful to
+append or prepend a system name to the number, so that if multiple
+machines file CDR's to the same database, you can separate them out.
+
+
+----------------------------------
CDR BEHAVIOR in various situations
----------------------------------
In each section, I wish to present what the CDR's should look like,
@@ -193,10 +122,6 @@
BLIND XFERS: (Only when C answers in the following sequences):
===========================================================
-The results vary on who does the xfer, and who is in
-which role: if we take care, we can guarantee that the
-bridge is occurring between one channel, and a peer, I hope!
-
Assuming the 'normal' case, A calls B, A is Chan role,
B is peer role:
@@ -204,103 +129,37 @@
Assume these event times:
e1: A's start time. (Set previously, perhaps)
- e2: A/B answer time (Set previously, perhaps)
+ e2: B answer time (Set previously, perhaps)
e3: B hits #, flashes hook, whatever to initiate
xfer and A starts getting MOH
- e4: B finishes dialing, hits a button, whatever,
- and ends his call.
+ e4: B finishes dialing, hits a button, whatever,
+ and ends his call. (B gets congestion, dialtone, whatever)
e5: C answers
e6: A or C hang up.
CDRs wanted: (src -> dest)
- CDR1: B -> C; start: e3 ans: e5 end: e6 AMA: DOCU type: BXFER Party: A
- CDR2: A -> B; start: e1 ans: e2 end: e6 AMA: BILL type: CALL Party: A
-
- B doing Xfer | A channel | A Peer
- ================+====================+=================
- | |
- B Channel | CASE 3. | CASE 2.
- | |
- ================+====================+=================
- | |
- B peer | CASE 1. | CASE 4.
- | |
- ================+====================+=================
-
-
- CASE 1:
- The 'normal' case. A has CDR, pbx, keeps both.
- C gets upgraded to Chan role; CDR records the
- call to C from B, Party set to A; Type to BXFER.
- start time set on C's CDR. When C answer, answ
- time set on C CDR. When A/C hangs up, the new
- CDR on C and the one on A will both be ended
- and posted. INVESTIGATE: will this work if
- there are further xfers/parks?
- CASE 2:
- This and the following cases hopefully will fall
- out if we manipulate the roles correctly.
-
- CASE 3:
-
- CASE 4:
-
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Party: A linkedID: abc1
+ CDR2: A start: e3 end: e5 type: HOLD linkedid: abc1
+ CDR3: B -> C; start: e3 ans: e5 end: e6 type: BXFER Party: A linkedID: abc1
+
Chan (A) does the xfer:
Assume these event times:
e1: A'a start time. (Set previously)
- e2: A/B answer time (Set previously)
+ e2: B answer time (Set previously)
e3: A hits #, flashes hook, whatever, to initiate
xfer and B starts getting MOH
- e4: A finishes dialing the xfer, hits a button, whatever,
+ e4: A finishes dialing the xfer, hits a button, whatever,
and ends his call.
e5: C answers, begins conversing with B
e6: B or C hang up.
CDRs wanted: (src -> dest)
- CDR1: A -> B; start: e1 ans: e2 end: e4 AMA: BILL type: CALL Party: A
- CDR2: A -> C; start: e3/e4 ans: e5 end: e6 AMA: DOCU type: BXFER Party: B
-
- A doing xfer | A channel | A Peer
- ================+====================+=================
- | |
- B Channel | CASE 3. | CASE 2.
- | |
- ================+====================+=================
- | |
- B peer | CASE 1. | CASE 4.
- | |
- ================+====================+=================
-
-
- CASE 1:
- the 'normal' case where the channel role xfers the
- peer to the newly dialed channel.
- C gets upgraded to Channel role, gets a CDR, start
- time set to moment C got created; C CDR answer time
- set when C answers (e5). type set to XFER. Party set
- to B. Since was channel, it will get congestion
- after it finishes dialing, and get hung up and its
- CDR published. Because C got marked as in Channel
- role, it will get its CDR published when it hangs
- up.
-
- CASE 2:
- if all works out well, we won't have to
- worry about these cases.
- CASE 3:
-
- CASE 4:
-
-
-
-
-(INVESTIGATE: I can't imagine a scenario where C could have any status
-at all; if it exists, it should be BUSY. So, PEER is the only possibility.
----Hmmmm. What if C is an external (FXO) line, and you want to treat it as a
-channel role?)
+ CDR1: A -> B; start: e1 ans: e2 end: e4 type: CALL Party: A linkedid: pqw40
+ CDR2: B start: e3 end: e5 type: HOLD linkedid: pqw40
+ CDR3: A -> C; start: e3 ans: e5 end: e6 type: BXFER Party: B linkedid: pqw40
@@ -315,7 +174,7 @@
a conference button, usually, that does the 3-way mixing
in the phone itself. Asterisk can't see these 3-ways.
-They follow this flow:
+They follow this flow (non-3way):
A and B are conversing. A (or B) performs some sequence
to initiate the attended xfer. (one touch via feature
@@ -342,80 +201,157 @@
Each variant might generate a different CDR
sequence.
-(a) C never answers. If this happens, it
- is as if nothing happened. No changes.
+Event times of interest:
+
+e1: A picks up; dials a destination
+e2: B answers
+e3: A or B hits initiates a transfer (#, hookflash, *2 or whatever)
+ The initiating party gets dialtone, the other party MOH.
+e4: C answers; the initiating party and C converse.
+e4b: C never answers... A and B are reconnected.
+e4d: A or B hangs up.
+e5: (optional) the initiating party (via hookflash or other method)
+ signals a 3-way to start
+e6: the initiating party hangs up; C and the other party are
+ now connected.
+e7: C or the other party hangs up.
+
+
+(a) C never answers. The attempt would get
+ recorded.
+
+ A initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: B start: e3 end: e4b type: HOLD Party: A linkedid: zzz33
+ CDR3: A -> C; start: e3 ans: end: e4b type: AXFER Disp: NO-ANS Party: B linkedid: zzz33
+ CDR4: A -> B; start: e4b ans: ? end: e4d type: RECONN Party: A linkedid: zzz33
+
+ B initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: A start: e3 end: e4 type: HOLD Party: B linkedid: zzz33
+ CDR3: B -> C; start: e3 ans: e4 end: e6 type: AXFER Disp: NO-ANS Party: A linkedid: zzz33
+ CDR4: B -> A; start: e4b ans: ? end: e4d type: RECONN Disp: ANSW Party: B linkedid: zzz33
(b) the transferer hangs up before C answers.
this should probably proceed like a blind
xfer.
+ A initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: B start: e3 end: e4 type: HOLD Party: A linkedid: zzz33
+ CDR3: A -> C; start: e3 ans: e4 end: e7 type: BXFER Disp: ANSW Party: B linkedid: zzz33
+
+ B initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: A start: e3 end: e4 type: HOLD Party: B linkedid: zzz33
+ CDR3: B -> C; start: e3 ans: e4 end: e7 type: BXFER Disp: ANSW Party: A linkedid: zzz33
+
(c) the transferer talks to C, and hangs up,
allowing the other two parties to be
bridged.
+CHANGE: One more CDR field! the AXFER2HUNGUP field, which records
+ who hung up to put the call in AXFER2 state. Only contains
+ data when type is AXFER2.
+
+ A initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: B start: e3 end: e4 type: HOLD Party: A linkedid: zzz33
+ CDR3: A -> C; start: e3 ans: e4 end: e6 type: AXFER1 Disp: ANSW Party: B linkedid: zzz33
+ CDR4: A -> C; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: B linkedid: zzz33 Hung: A
+
+ B initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: A start: e3 end: e4 type: HOLD Party: B linkedid: zzz33
+ CDR3: B -> C; start: e3 ans: e4 end: e6 type: AXFER1 Disp: ANSW Party: B linkedid: zzz33
+ CDR4: B -> C; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: A linkedid: zzz33 Hung: B
+
+<?> The question mark on answer times indicates that we could just leave the answer time NULL.
+
(d) the transferer engages a 3-way, to
which the transferer hangs up first.
the other two parties are still bridged.
+ A initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: B start: e3 end: e4 type: HOLD Party: A linkedid: zzz33
+ CDR3: A -> C; start: e3 ans: e4 end: e5 type: AXFER1 Disp: ANSW Party: A linkedid: zzz33
+ CDR3: A -> C; start: e5 ans: e5? end: e6 type: 3WAY Disp: ANSW Party: B linkedid: zzz33
+ CDR4: A -> C; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: B linkedid: zzz33 Hung: A
+
+ B initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: A start: e3 end: e4 type: HOLD Party: B linkedid: zzz33
+ CDR3: B -> C; start: e3 ans: e4 end: e6 type: AXFER1 Disp: ANSW Party: B linkedid: zzz33
+ CDR3: B -> C; start: e5 ans: e5? end: e6 type: 3WAY Disp: ANSW Party: A linkedid: zzz33
+ CDR4: B -> C; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: A linkedid: zzz33 Hung: B
+
+<?> The question mark on answer times indicates that we could just leave the answer time NULL.
+
(e) the transferer engages a 3-way, to
- which the transferee (C) hangs up first.
+ which the transferee (C) hangs up first (time e6).
the other two parties are still bridged.
+
+ A initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: B start: e3 end: e4 type: HOLD Party: A linkedid: zzz33
+ CDR3: A -> C; start: e3 ans: e4 end: e5 type: AXFER1 Disp: ANSW Party: A linkedid: zzz33
+ CDR3: A -> C; start: e5 ans: e5? end: e6 type: 3WAY Disp: ANSW Party: B linkedid: zzz33
+ CDR4: A -> B; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: B linkedid: zzz33 Hung: C
+
+ B initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: A start: e3 end: e4 type: HOLD Party: B linkedid: zzz33
+ CDR3: B -> C; start: e3 ans: e4 end: e6 type: AXFER1 Disp: ANSW Party: B linkedid: zzz33
+ CDR3: B -> C; start: e5 ans: e5? end: e6 type: 3WAY Disp: ANSW Party: A linkedid: zzz33
+ CDR4: B -> A; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: A linkedid: zzz33 Hung: C
+
+<?> The question mark on answer times indicates that we could just leave the answer time NULL.
+
+QUESTION: what if we let Party store who previously hung up and thus started the AXFER2 state?
(f) the transferer engages a 3-way, to
which the transferred party hangs up first.
the other two parties are still bridged.
-(g) finally, one/both of the remaining parties
- hang up and a final CDR is generated.
-
-
-1. A is bridged to B; B attended xfers A to C
-
- | A channel | A Peer
- ================+====================+=================
- | |
- B Channel | CASE 3. | CASE 2.
- | |
- ================+====================+=================
- | |
- B peer | CASE 1. | CASE 4.
- | |
- ================+====================+=================
-
- CASE 1:
-
- CASE 2:
-
- CASE 3:
-
- CASE 4:
-
-
-2. A is bridged to B; A attended xfers B to C
-
- | A channel | A Peer
- ================+====================+=================
- | |
- B Channel | CASE 3. | CASE 2.
- | |
- ================+====================+=================
- | |
- B peer | CASE 1. | CASE 4.
- | |
- ================+====================+=================
-
- CASE 1:
-
- CASE 2:
-
- CASE 3:
-
- CASE 4:
-
+ A initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: B start: e3 end: e4 type: HOLD Party: A linkedid: zzz33
+ CDR3: A -> C; start: e3 ans: e4 end: e5 type: AXFER1 Disp: ANSW Party: A linkedid: zzz33
+ CDR3: A -> C; start: e5 ans: e5? end: e6 type: 3WAY Disp: ANSW Party: B linkedid: zzz33
+ CDR4: A -> C; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: A linkedid: zzz33 Hung: B
+
+ B initiates xfer:
+
+ CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Disp: ANSW Party: A linkedid: zzz33
+ CDR2: A start: e3 end: e4 type: HOLD Party: B linkedid: zzz33
+ CDR3: B -> C; start: e3 ans: e4 end: e6 type: AXFER1 Disp: ANSW Party: B linkedid: zzz33
+ CDR3: B -> C; start: e5 ans: e5? end: e6 type: 3WAY Disp: ANSW Party: A linkedid: zzz33
+ CDR4: A -> C; start: e6 ans: e6? end: e7 type: AXFER2 Disp: ANSW Party: A linkedid: zzz33 Hung: A
+
+<?> The question mark on answer times indicates that we could just leave the answer time NULL.
+
+QUESTION: what if we let Party store who previously hung up and thus started the AXFER2 state?
+
+
===========================================================
Parking
===========================================================
+
+CHANGE: The parking lot stall really should be recorded in a
+ CDR field, we'll call it ParkingStall
1. A is bridged to B; A parks B
@@ -438,43 +374,20 @@
b is hung-up.
(a)
- CDR1: A -> B; start: e1; ans: e2; end: e3 AMA: BILL type: CALL Party: B
- CDR2: A -> B; start: e3; ans: NIL; end: e4 AMA: DOCU type: PARK Party: B
+ CDR1: A -> B; start: e1; ans: e2; end: e3 type: CALL Party: B linkedid: rtw97
+ CDR2: A -> B; start: e3; ans: NIL; end: e4 type: PARK Party: B linkedid: rtw97 ParkingStall: 701 at default
(b)
- CDR1: A -> B; start: e1; ans: e2; end: e6 AMA: BILL type: CALL Party: B
- CDR2: A -> B; start: e3; ans: NIL; end: e5 AMA: DOCU type: PARK Party: B
+ CDR1: A -> B; start: e1; ans: e2; end: e3 type: CALL Party: B linkedid: rtw97
+ CDR2: A -> B; start: e3; ans: NIL; end: e5 type: PARK Party: B linkedid: rtw97 ParkingStall: 701 at default
+ CDR3: A -> B; start: e4a; ans: e5; end: e6 type: RECALL Party: A linkedid: rtw97
(c)
- CDR1: A -> B; start: e1; ans: e2; end: e3 AMA: BILL type: CALL Party: B
- CDR2: A -> B; start: e3; ans: NIL; end: e8 AMA: DOCU type: PARK Party: B
- CDR3: C -> B; start: e7; ans: e8 end: e9 AMA: BILL type: CALL Party: B
-
-
-
- | A channel | A Peer
- ================+====================+=================
- | |
- | |
- B Channel | CASE 1. | CASE 2.
- | |
- | |
- ================+====================+=================
- | |
- | |
- B peer | CASE 3. | CASE 4.
- | |
- | |
- ================+====================+=================
-
- CASE 1:
-
- CASE 2:
-
- CASE 3:
-
- CASE 4:
-
+ CDR1: A -> B; start: e1; ans: e2; end: e3 type: CALL Party: B linkedid: rtw97
+ CDR2: A -> B; start: e3; ans: NIL; end: e8 type: PARK Party: B linkedid: rtw97 ParkingStall: 701 at default
+ CDR3: C -> B; start: e7; ans: e8 end: e9 type: CALL Party: B linkedid: rtw97
+
+
2. A is bridged to B; B parks A
@@ -482,29 +395,132 @@
b. A stays online to parking expiry, then reconnected to A
c. A is picked up by C.
- | A channel | A Peer
- ================+====================+=================
- | |
- | |
- B Channel | CASE 1. | CASE 2.
- | |
- | |
- ================+====================+=================
- | |
- | |
- B peer | CASE 3. | CASE 4.
- | |
- | |
- ================+====================+=================
-
- CASE 1:
-
- CASE 2:
-
- CASE 3:
-
- CASE 4:
-
-
-
-
+ Assume these event times:
+ e1: A starts
+ e2: B answers
+ e3: B initiates parking via one-touch, dialing parking exten, whatever
+ and A starts getting MOH
+ e4: A hangs up before parking expiry,
+ e4a: at expiry time, a call is initiated to B
+ e5: A reconnects to B
+ e6: A or B hang up.
+ e7: C picks up (then dials parking exten)
+ e8: A and C are connected
+ e9: A or C hangs up.
+ e10: where A stays on, parking expiry reached, B does not answer...
+ A is hung-up.
+
+ (a)
+ CDR1: A -> B; start: e1; ans: e2; end: e3 type: CALL Party: B linkedid: gyq49
+ CDR2: A -> B; start: e3; ans: NIL; end: e4 type: PARK Party: A linkedid: gyq49 ParkingStall: 701 at default
+
+ (b)
+ CDR1: A -> B; start: e1; ans: e2; end: e3 type: CALL Party: B linkedid: gyq49
+ CDR2: A -> B; start: e3; ans: NIL; end: e5 type: PARK Party: A linkedid: gyq49 ParkingStall: 701 at default
+ CDR3: A -> B; start: e4a; ans: e5; end: e6 type: RECALL Party: A linkedid: gyq49
+
+ (c)
+ CDR1: A -> B; start: e1; ans: e2; end: e3 type: CALL Party: B linkedid: gyq49
+ CDR2: A -> B; start: e3; ans: NIL; end: e8 type: PARK Party: A linkedid: gyq49 ParkingStall: 701 at default
+ CDR3: C -> B; start: e7; ans: e8 end: e9 type: CALL Party: B linkedid: gyq49
+
+
+===========================================================
+Conference calls
+===========================================================
+
+Conference calls are another area that CDR's should cover, but currently do not.
+A 'leg' should include the times an attendee was connected to a conference,
+and disconnected. The conference should be tied together by the linkedid and the conference
+number, but if the linkedID does its job correctly, it should suffice to
+identify all the participants in a conference. If the same conference ID is
+used multiple times, the linkedID should vary from one meeting to the next,
+as long as all participants exit from one meeting to the next.
+
+A CONF type CDR will be issued.
+
+CHANGE: Add a conferenceID field to the CDR list.
+
+<MORE TO COME>
+
+
+==============================================
+ MIXED SCENARIOS
+==============================================
+
+This stuff isn't going to do us any good unless
+it can smoothly represent complicated, mixed
+scenarios properly. So, let's invent a few, and
+see if it holds up nicely.
+
+
+
+
+---------
+TYPE LIST
+---------
+
+Here is a list of the CDR types, and what special meanings
+apply to CDR fields for that type:
+
+Type
+----
+
+CALL a user-initiated call, usually via Dial or Queue or Meetme applications.
+
+PARK a user has been Parked. The Party field records who is parked. The
+ ParkingStall field records which parking stall the parked channel was
+ sent to.
+
+BXFER A blind transfer has occurred. The src field records the caller; the dest
+ field records the successfully reached target; the Party field records
+ who the call was transferred to. For this segment, the two parties
+ conversing were the target and the Party that was transferred. The
+ transferer was hung up at the start time.
+
+AXFER An attempt to do an assisted xfer. The disposition will not be ANSWERED.
+
+
+AXFER1 The state in the assisted transfer, where, if A axfers B to C, A is
+ talking to C, and B is on hold.
+
+AXFER2 A state in the assisted Transfer sequence, where:
+ (a) the referer and the referee (A) and (C) have had a conversation,
+ and A has hung up to allow B and C to converse
+ (b) One of the parties of a 3-way conversation has hung up
+ to allow the other two parties to converse. the AXFER2HUNGUP field
+ records which party of the two or three hung up. The start time
+ records the time of hangup.
+
+HOLD A state where the src is being played nothing but music on hold;
+ this occurs during assisted xfers, and possibly in other scenarios.
+
+3WAY src, dest, and Party are all conferenced together via Asterisk. This
+ most commonly occurred in dahdi channels, that can handle it. SIP phones
+ usually do this at the phone, so all you might see is two calls going
+ on to the same device at the same time.
+
+RECALL a system-initiated call, usually to a single specific target, otherwise
+ similar to CALL. Occurs when PARKed calls expire;
+
+CONF a Meetme Conference participation.
+
+RECONN This happens when an attended transfer is attempted, but the target
+ party does not answer the phone. When the ringing times out, the
+ transferer and the original party are reconnected. The src and dest
+ fields should describe the two parties.
+
+BARGE Records the time period while someone is 'barging' a channel (eavesdropping).
+ Src describes the channel doing the barge. Dest is the channel being listened
+ to. (Party might list who is connected to dest).
+
+WHISPER Records the time period while one channel 'whispers' into another. src is the
+ channel doing the whispering. Dest is the channel being whispered to.
+
+
+QUESTION: What other kinds of inter-channel interactions are possible? RESEARCH: go
+ thru apps & funcs and find possible interactions.
+
+
+
+
More information about the asterisk-commits
mailing list