Review Board 1.7.16

Add Connected line interception macros to Asterisk

Review Request #256 - Created May 27, 2009 and submitted

Mark Michelson
Connected line reception and transmission is a new feature in Asterisk trunk. One of its shortcomings is the inability to modify received connected line information while a dialplan application is running. 

Here is a common example where this may be useful. Many office environments require that a digit (such as '9') is dialled in order to reach the PSTN. The problem is that when one dials a PSTN number, the information received from the far end will not have this prefix digit. To make the lives of users easier, it would be really nice if the prefix digit could be displayed for them.

This proposed patch adds the ability to add connected line interception macros into the dialplan. When we are going to send a connected line update to someone, the administrator has the ability to run a macro which can do whatever manipulation of connected line information is necessary to appease everyone. There are four defined macros in the channelvariables.tex file.

${CONNECTED_LINE_SEND_CALLEE_MACRO}        Macro to call before sending a connected line update to the callee
${CONNECTED_LINE_SEND_CALLER_MACRO}        Macro to call before sending a connected line update to the caller

So in the example I gave above, the administrator could write a simple macro like this:

exten => s,1,Set(CONNECTEDLINE(num,i)=9${CONNECTEDLINE(num)}); Adds '9' to the connected line number

Then, he could add a priority before any Dial to the PSTN:
exten => blah,n,Set(CONNECTED_LINE_SEND_CALLER_MACRO=addnine)

Simple as that! And of course, one is not limited to modifying just the connected line number. You could modify the name, or even information not relating to connected line information.

Please review my code and see if there is anything that needs fixing. I realize as I am typing this that I have not placed anything in the CHANGES file, so I need to do that soon.i
I have tested this with a scenario similar to what I listed above. In addition, I tested features such as call pickup (both using the Pickup application and the pickupexten from features.conf), built-in blind and attended transfers, and SIP transfers.
Review request changed
Updated (June 1, 2009, 8:48 a.m.)
Addressed Russell's comments. Re-tested to be sure that the interception macros were called properly.
Ship it!
Posted (June 1, 2009, 10 a.m.)
Other than this one comment, and some trailing whitespace in the header file changes, this looks good to go.

Nice work, Mark!
/trunk/main/channel.c (Diff revision 2)
Hm, this seems kind of weird.  Why do we reset jitterbuffer state on a connected line update?  It seems as if the code is trying to infer more from the update than it should.

There are other mechanisms, such as the SSRC changing in RTP, to detect when the source of the media has changed and jitterbuffer state should be reset.  I think that it should be removed from this code.

This same comment goes for the handling of AST_CONTROL_REDIRECTING, even though that is not being changed in this patch. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to