[asterisk-dev] [Code Review] Enhancements to connected line and redirecting work.

[Mark Michelson]

> On 2010-05-12 17:04:58, rmudgett wrote:
> >

Thanks for the review, Richard! I have addressed all of the below points including the ones I have not left specific comments on.


> On 2010-05-12 17:04:58, rmudgett wrote:
> > /trunk/include/asterisk/channel.h, lines 2798-2825
> > <https://reviewboard.asterisk.org/r/652/diff/1/?file=10014#file10014line2798>
> >
> >     More red spots

Review board makes this one look much worse than it should have been. It appears that all of these red spots are tabs. In actuality, there is just an extra space so that the second line of, say, a param note will line up with the word "param" instead of the backslash that precedes "param." In the interest of appeasing review board (and since adding the space really doesn't enhance readability very much) I'll just remove the offending spaces.


> On 2010-05-12 17:04:58, rmudgett wrote:
> > /trunk/main/rtp_engine.c, lines 1109-1116
> > <https://reviewboard.asterisk.org/r/652/diff/1/?file=10019#file10019line1109>
> >
> >     Control will never reach these lines.  I think these lines are in the wrong place.

Yep, these are nested one level too deeply. You'll notice that there is a very similar construct earlier in the file and I got it correct there. I also was not properly calling ast_frfree in most cases, so I have added those in now as well.


> On 2010-05-12 17:04:58, rmudgett wrote:
> > /trunk/main/rtp_engine.c, line 1118
> > <https://reviewboard.asterisk.org/r/652/diff/1/?file=10019#file10019line1118>
> >
> >     Red spot

I believe I got this spot when correcting your above note. A humble request: if you are going to point out a red spot that has no other text on the line, could you included maybe a couple of lines above and below the red spot so that it is more clear where the spot is? The line number helps some, but in quite a few cases, the line number is not enough because lines may be offset by some amount due to svn updates or other reasons. Thanks!


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/652/#review2005
-----------------------------------------------------------


On 2010-05-07 12:27:29, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/652/
> -----------------------------------------------------------
> 
> (Updated 2010-05-07 12:27:29)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Digium has a commercial customer who has made extensive use of the connected party and
> redirecting information present in later versions of Asterisk Business Edition and which
> is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
> have come about. This patch adds several enhancements to maximize usage of the connected party
> and redirecting information functionality.
> 
> First, Asterisk trunk already had connected line interception macros. These macros allow you to
> manipulate connected line information before it was sent out to its target. This patch adds the
> same feature except for redirecting information instead.
> 
> Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
> tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
> mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
> that it can be set to whatever value the administrator likes. Later, when running connected line
> and redirecting macros, the admin can read the tag off the appropriate structure to determine what
> action to take. You can think of this sort of like a channel variable, except that instead of having
> the variable associated with a channel, the variable is associated with a specific identity within
> Asterisk.
> 
> Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
> caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
> a specific calling presentation value on the outgoing channel.
> 
> Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
> to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
> being transferred would not have the opportunity to run a connected line interception macro to
> possibly alter the transfer target's connected line information. The issue here was that during a
> blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
> update. The way this was corrected was to add this new control frame subclass. Now, we queue an
> AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
> be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
> associated with the specific read action the control frame describes. In this case, the action taken
> is to run the connected line interception macro on the transferee's channel.
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_dial.c 261563 
>   /trunk/apps/app_queue.c 261563 
>   /trunk/channels/chan_dahdi.c 261563 
>   /trunk/channels/chan_local.c 261563 
>   /trunk/channels/chan_misdn.c 261563 
>   /trunk/channels/chan_sip.c 261563 
>   /trunk/channels/misdn/chan_misdn_config.h 261563 
>   /trunk/channels/misdn/isdn_lib.h 261563 
>   /trunk/channels/misdn_config.c 261563 
>   /trunk/channels/sip/include/sip.h 261563 
>   /trunk/funcs/func_callerid.c 261563 
>   /trunk/funcs/func_connectedline.c 261563 
>   /trunk/funcs/func_redirecting.c 261563 
>   /trunk/include/asterisk/channel.h 261563 
>   /trunk/include/asterisk/frame.h 261563 
>   /trunk/main/channel.c 261563 
>   /trunk/main/dial.c 261563 
>   /trunk/main/features.c 261563 
>   /trunk/main/rtp_engine.c 261563 
> 
> Diff: https://reviewboard.asterisk.org/r/652/diff
> 
> 
> Testing
> -------
> 
> The Digium customer mentioned before has done extensive testing of connected line and redirecting
> scenarios, as has Digium's Product Qualification department.
> 
> 
> Thanks,
> 
> Mark
> 
>