[asterisk-dev] An idea: Interception macro for registering overlap dialling

[Pavel Troller]

Hi!
  Thanks to Richard's help with my recent (rather stupid) question regarding
the Connected Party Number handling, I've familiarized using the Interception
Macros for this purpose and I am very happy with them.
  I think I have an idea for further usage of such a kind of macro: to
register the digits bridged in the overlap dialling process.
  Let's assume a scenario, where an outgoing call is made to a trunk allowing
overlap dialling (say, DAHDI/PRI) from a technology allowing overlap receiving
(say DAHDI/analog or PRI, IAX2, SIP with allowoverlap=dtmf etc.). The example
dialplan entry would be very simple, say 
exten => 9,1,Dial(DAHDI/i2) 
so immediately after receiving the extension code, the connection is made 
(the caller can hear the external dial tone) and further dialling is then
transferred in overlap mode.
  In current Asterisk implementation (1.8), I don't know about a method, how to
bring the dialled digits to the Asterisk's "consciousness", they are just 
being bridged automatically but they don't appear anywhere (neither in CDR
nor in CEL) and they cannot be retrieved even after the call is hung, for 
example using the "h" extension.
  If there would be an interception macro, which would trigger for every digit
being bridged, it would be possible to populate all the necessary places with
them (custom CDR fields, database entries for "Last Number Redial" feature etc.).
The digit(s) could be passed to the macro by means of a special variable.
How complex would it be to add such a possibility ? I've looked at the sources,
but the internal code path, which is used to transfer the signalling including
the overlap dialling events, is too complex for me to even find a good place,
where such a feature could be inserted to the code.
  Please note that I don't want to register any DTMF going over the answered
connection, what I want is just the overlap dialling phase (i.e. before the call
is answered or the Proceeding event is received in the backward direction).
  Is this idea at least partially feasible, or is this just a junk ? 
  Or am I stupid again and is this already handled somehow and just I'm such an
idiot that I don't know about it ?
  With regards,
    Pavel