[asterisk-commits] murf: branch murf/RFCs r157223 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Sat Nov 15 14:21:23 CST 2008
Author: murf
Date: Sat Nov 15 14:21:23 2008
New Revision: 157223
URL: http://svn.digium.com/view/asterisk?view=rev&rev=157223
Log:
Just starting... get the outline together, populate fully later
Added:
team/murf/RFCs/CDRfix2.rfc.txt (with props)
Added: team/murf/RFCs/CDRfix2.rfc.txt
URL: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=auto&rev=157223
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (added)
+++ team/murf/RFCs/CDRfix2.rfc.txt Sat Nov 15 14:21:23 2008
@@ -1,0 +1,344 @@
+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 what the community needs/wants.
+
+But, going through the effort wasn't a total waste of time; lessons were learned, and experience gained.
+
+There's always CEL... but we don't have the main piece yet... a module to convert CEL events to
+CDR records.
+
+And, CEL doesn't solve a problem that exists in the code, that needs to be addressed, and
+affects not only CDR's, but when/where/how the h (hangup) extension gets run. Parking and
+transfers affect this code.
+
+So, I'm going to spec out my changes completely before I change one line of code. I want/need
+to see the end of the journey before I take the first step this time.
+And when I do change the code, all the changes will be optional via a compile option.
+
+CHANGE: add a 'make menuselect" option (in Compiler Options) to set 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 i
t 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.
+
+
+Am I thinking clearly?
+
+CDR BEHAVIOR in various situations
+----------------------------------
+In each section, I wish to present what the CDR's should look like,
+and when the h-exten gets run, on what channel.
+
+CHANGE: Intro new CDR field: "type" vals PARK, BXFER, AXFER, CALL
+CHANGE: Intro new CDR field: "Party". It contains the the channel
+ name of the "Party" that was connected to Dest by Src when
+ type is "BXFER" or "AXFER".
+
+===========================================================
+BLIND XFERS: (Only when C answers in the following sequences):
+===========================================================
+
+This involves these kinds of issues: A, B, and C could each
+have CHANNEL or PEER role before/during the call.
+
+1. A calls B; B blind xfers A to C
+
+ | A channel | A Peer
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 5. | CASE 6.
+ | |
+ | |
+ B Channel | C peer | C peer
+ | |
+ | CASE 3. | CASE 2.
+ | |
+ | |
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 7. | CASE 8.
+ | |
+ | |
+ B peer | C peer | C peer
+ | |
+ | CASE 1. | CASE 4.
+ | |
+ | |
+ ================+====================+=================
+ Assume these event times:
+ e1: A starts
+ e2: B answers
+ 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: C answers
+ e5: A or C hang up.
+
+ C is a peer (4 cases):
+ CASE 1:
+ CDRs wanted: (src -> dest)
+ CDR1: B -> C; start: e3 ans: e4 end: e5 AMA: DOCU type: BXFER Party: A
+ CDR2: A -> B; start: e1 ans: e2 end: e5 AMA: BILL type: CALL Party: A
+
+ CASE 2:
+
+ CASE 3:
+
+ CASE 4:
+
+ C is a channel (4 cases):
+ CASE 5:
+
+ CASE 6:
+
+ CASE 7:
+
+ CASE 8:
+
+
+
+2. A calls B; A blind xfers to C
+
+ | A channel | A Peer
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 5. | CASE 6.
+ | |
+ | |
+ B Channel | C peer | C peer
+ | |
+ | CASE 3. | CASE 2.
+ | |
+ | |
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 7. | CASE 8.
+ | |
+ | |
+ B peer | C peer | C peer
+ | |
+ | CASE 1. | CASE 4.
+ | |
+ | |
+ ================+====================+=================
+
+ CASE 1:
+
+ CASE 2:
+
+ CASE 3:
+
+ CASE 4:
+
+ CASE 5:
+
+ CASE 6:
+
+ CASE 7:
+
+ CASE 8:
+
+
+===========================================================
+Attended Xfer:
+===========================================================
+
+1. A calls B; B attended xfers A to C
+
+ | A channel | A Peer
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 5. | CASE 6.
+ | |
+ | |
+ B Channel | C peer | C peer
+ | |
+ | CASE 3. | CASE 2.
+ | |
+ | |
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 7. | CASE 8.
+ | |
+ | |
+ B peer | C peer | C peer
+ | |
+ | CASE 1. | CASE 4.
+ | |
+ | |
+ ================+====================+=================
+
+ CASE 1:
+
+ CASE 2:
+
+ CASE 3:
+
+ CASE 4:
+
+ CASE 5:
+
+ CASE 6:
+
+ CASE 7:
+
+ CASE 8:
+
+
+
+2. A calls B; A attended xfers B to C
+
+ | A channel | A Peer
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 5. | CASE 6.
+ | |
+ | |
+ B Channel | C peer | C peer
+ | |
+ | CASE 3. | CASE 2.
+ | |
+ | |
+ ================+====================+=================
+ | C channel | C channel
+ | |
+ | CASE 7. | CASE 8.
+ | |
+ | |
+ B peer | C peer | C peer
+ | |
+ | CASE 1. | CASE 4.
+ | |
+ | |
+ ================+====================+=================
+
+ CASE 1:
+
+ CASE 2:
+
+ CASE 3:
+
+ CASE 4:
+
+ CASE 5:
+
+ CASE 6:
+
+ CASE 7:
+
+ CASE 8:
+
+
+===========================================================
+Parking
+===========================================================
+
+1. A calls B; A parks B
+
+ a. B hangs up before parking expiry
+ b. B stays online to parking expiry, then reconnected to A
+ c. B 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:
+
+
+2. A calls B; B parks A
+
+ a. A hangs up before parking expiry
+ 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:
+
+
+
+
Propchange: team/murf/RFCs/CDRfix2.rfc.txt
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: team/murf/RFCs/CDRfix2.rfc.txt
------------------------------------------------------------------------------
svn:keywords = Author Id Date Revision
Propchange: team/murf/RFCs/CDRfix2.rfc.txt
------------------------------------------------------------------------------
svn:mime-type = text/plain
More information about the asterisk-commits
mailing list