[asterisk-commits] murf: branch murf/RFCs r157296 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Tue Nov 18 10:53:20 CST 2008
Author: murf
Date: Tue Nov 18 10:53:20 2008
New Revision: 157296
URL: http://svn.digium.com/view/asterisk?view=rev&rev=157296
Log:
format the single line paragraph into something a little
nicer.
Flesh in the Blind Xfer a little more.
Begin on the Attended Xfer.
No-one should be shocked at the crude state of this
doc. I hope!
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=157296&r1=157295&r2=157296
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (original)
+++ team/murf/RFCs/CDRfix2.rfc.txt Tue Nov 18 10:53:20 2008
@@ -1,66 +1,177 @@
-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. (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
-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.
+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. (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 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:
+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.
+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.
-
+
+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?
@@ -82,9 +193,18 @@
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:
+
+Peer (B) does the xfer:
+
Assume these event times:
- e1: either channel's start time. (Set previously)
- e2: either channel's answer time (Set previously)
+ e1: A's start time. (Set previously, perhaps)
+ e2: A/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,
@@ -96,75 +216,155 @@
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
-
-This involves these kinds of issues: A, and B, could each
-have CHANNEL or PEER role before/during the call.
-
-I can't imagine a scenario where C could have any status
+ 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:
+
+
+
+Chan (A) does the xfer:
+
+ Assume these event times:
+ e1: A'a start time. (Set previously)
+ e2: A/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,
+ 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.
-
-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: 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.
- e5: C answers
- e6: A or C hang up.
-
- C is in peer role (4 cases):
- CASE 1:
-
- 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:
-
-
+---Hmmmm. What if C is an external (FXO) line, and you want to treat it as a
+channel role?)
+
+
===========================================================
Attended Xfer:
===========================================================
+
+Attended Xfers Involve 3 parties, but can involve 3-ways.
+3 ways are either handled by the phone, or the channel
+driver. For instance on phones with Dahdi interfaces,
+you can do 3-ways using hookflashes. SIP phones provide
+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:
+
+A and B are conversing. A (or B) performs some sequence
+to initiate the attended xfer. (one touch via feature
+# or * dtmf, hookflash, buttons on sip phone, etc)
+
+B (or A) gets put on hold, while the person doing the
+xfer gets a dialtone. The transferer dials the target
+extension (C), and the target extension (C) answers.
+
+A (or B) and C converse privately.
+
+At this point A (or B) can hang up for the simple
+one-touch call forwarding scenario. B (or A) is
+connected (bridged) to C.
+
+But (when the 'one-touch' feature is not used) A
+(or B) can also form a 3-way conversation in some
+cases, and all 3 can converse. A can hang up,
+and leave B and C talking, or for that matter,
+B can hang up, and leave A and C talking. I'd
+imagine that C could hang up and leave A and B
+conversing, as at the beginning.
+
+Each variant might generate a different CDR
+sequence.
+
+(a) C never answers. If this happens, it
+ is as if nothing happened. No changes.
+
+(b) the transferer hangs up before C answers.
+ this should probably proceed like a blind
+ xfer.
+
+(c) the transferer talks to C, and hangs up,
+ allowing the other two parties to be
+ bridged.
+
+(d) the transferer engages a 3-way, to
+ which the transferer hangs up first.
+ the other two parties are still bridged.
+
+(e) the transferer engages a 3-way, to
+ which the transferee (C) hangs up first.
+ the other two parties are still bridged.
+
+(f) the transferer engages a 3-way, to
+ which the transferred party hangs up first.
+ the other two parties are still bridged.
+
1. A is bridged to B; B attended xfers A to C
More information about the asterisk-commits
mailing list