[asterisk-commits] murf: branch murf/RFCs r157243 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Mon Nov 17 10:12:55 CST 2008
Author: murf
Date: Mon Nov 17 10:12:54 2008
New Revision: 157243
URL: http://svn.digium.com/view/asterisk?view=rev&rev=157243
Log:
If you are dialing device C, it will be busy if it's
connected to anything. So, the only role a new
dialed channel could be in, is "peer".
So, get rid of the extra cases. Also, the bridged
channels could be in any state, not just those resulting
from dialing, but xfers, parks, etc, so make the verbage
more general.
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=157243&r1=157242&r2=157243
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (original)
+++ team/murf/RFCs/CDRfix2.rfc.txt Mon Nov 17 10:12:54 2008
@@ -3,7 +3,8 @@
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.
+CDR records. (This document may also well serve as a specification for what the CEL->CDR generator
+is expected to do.)
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
@@ -71,7 +72,7 @@
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".
+ type is "BXFER" or "AXFER", or the party parked.
Also, in the following, I split everything out into multiple
cases. It is my hope that, the cases will fold nicely into
@@ -81,210 +82,127 @@
BLIND XFERS: (Only when C answers in the following sequences):
===========================================================
-This involves these kinds of issues: A, B, and C could each
+This involves these kinds of issues: A, and B, 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.
- | |
+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.
+
+1. A is bridged to B; B blind xfers A to C
+
+ | A channel | A Peer
+ ================+====================+=================
+ | |
+ B Channel | CASE 3. | CASE 2.
+ | |
+ ================+====================+=================
+ | |
+ B peer | CASE 1. | CASE 4.
| |
================+====================+=================
Assume these event times:
- e1: A starts
- e2: B answers
+ e1: either channel's start time. (Set previously)
+ e2: either channel's answer time (Set previously)
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):
+ e5: C answers
+ e6: A or C hang up.
+
+ C is in peer role (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:
+ 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
+
+ CASE 2: I need to find a scenario, where B could be dialing A, with A in the Peer role...
+ and not dialing as an xfer or park case.
+
+
+ CASE 3: Hmmm. A is...
+
+ CASE 4:
+
+
+
+
+2. A is bridged to B; A blind 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:
+
===========================================================
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:
-
+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:
+
===========================================================
Parking
===========================================================
-1. A calls B; A parks B
+1. A is bridged to B; A parks B
a. B hangs up before parking expiry, or expiry and A does not answer
b. B stays online to parking expiry, then reconnected to A
@@ -339,7 +257,7 @@
CASE 4:
-2. A calls B; B parks A
+2. A is bridged to B; B parks A
a. A hangs up before parking expiry
b. A stays online to parking expiry, then reconnected to A
More information about the asterisk-commits
mailing list