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

[rmudgett at digium.com]

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

Ship it!


I verified that the items I pointed out before looked OK now.

Only picky stuff left.


/trunk/channels/chan_dahdi.c
<https://reviewboard.asterisk.org/r/652/#comment4294>

    Attack of the reds.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/652/#comment4295>

    If you want to be really picky: casting space!



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/652/#comment4296>

    Casting space.



/trunk/channels/misdn_config.c
<https://reviewboard.asterisk.org/r/652/#comment4297>

    MSN should be capitalized since it is an acronym.



/trunk/configs/misdn.conf.sample
<https://reviewboard.asterisk.org/r/652/#comment4293>

    Change to:
    ; MSN.
    ; Default is no.



/trunk/main/rtp_engine.c
<https://reviewboard.asterisk.org/r/652/#comment4292>

    Arrrg... too much indention!


- rmudgett


On 2010-05-13 15:20:39, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/652/
> -----------------------------------------------------------
> 
> (Updated 2010-05-13 15:20:39)
> 
> 
> 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_queue.c 262999 
>   /trunk/channels/chan_dahdi.c 262999 
>   /trunk/channels/chan_local.c 262999 
>   /trunk/apps/app_dial.c 262999 
>   /trunk/channels/chan_misdn.c 262999 
>   /trunk/channels/chan_sip.c 262999 
>   /trunk/channels/misdn/chan_misdn_config.h 262999 
>   /trunk/channels/misdn/isdn_lib.h 262999 
>   /trunk/channels/misdn_config.c 262999 
>   /trunk/channels/sip/include/sip.h 262999 
>   /trunk/configs/misdn.conf.sample 262999 
>   /trunk/funcs/func_callerid.c 262999 
>   /trunk/funcs/func_connectedline.c 262999 
>   /trunk/funcs/func_redirecting.c 262999 
>   /trunk/include/asterisk/channel.h 262999 
>   /trunk/include/asterisk/frame.h 262999 
>   /trunk/main/channel.c 262999 
>   /trunk/main/dial.c 262999 
>   /trunk/main/features.c 262999 
>   /trunk/main/rtp_engine.c 262999 
> 
> 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
> 
>