[asterisk-dev] [Code Review] 2383: Refactor Dialing to publish Stasis-Core messages

[Matt Jordan]

> On April 1, 2013, 7:07 p.m., David Lee wrote:
> > /trunk/main/dial.c, line 662
> > <https://reviewboard.asterisk.org/r/2383/diff/6/?file=35139#file35139line662>
> >
> >     Stray s at the end of the comment.

Fixed


> On April 1, 2013, 7:07 p.m., David Lee wrote:
> > /trunk/include/asterisk/stasis_channels.h, lines 20-21
> > <https://reviewboard.asterisk.org/r/2383/diff/6/?file=35136#file35136line20>
> >
> >     In extracting this stuff to its own file, you dropped the '\addtogroup StasisTopicsAndMessages' doxygen tag I had added to trunk. Please put the back :-)

Restored


> On April 1, 2013, 7:07 p.m., David Lee wrote:
> > /trunk/include/asterisk/channel.h, line 368
> > <https://reviewboard.asterisk.org/r/2383/diff/6/?file=35135#file35135line368>
> >
> >     Seriously, you've got an encoding problem here. Not sure what encoding your editor is using, but everything else seems to be expecting UTF-8.

No idea why Eclipse didn't enjoy it. Vim should have fixed it.


> On April 1, 2013, 7:07 p.m., David Lee wrote:
> > /trunk/apps/app_dial.c, lines 1094-1108
> > <https://reviewboard.asterisk.org/r/2383/diff/6/?file=35133#file35133line1094>
> >
> >     This is a copy of the function in main/dial.c. Tsk, tsk.

{quote}
2. The publishing of dial information has been expanded to dial.c in anticipation of the early bridging work. Note that this means there is a small duplication of code between dial.c and app_dial.c, it is anticipated that as app_dial.c is refactored to use dial.c, this code duplication will be cease to exist. (It's useful for now, however, as it let's us build up tests for app_dial)
{quote}

I'm not a fan of having that duplicated either, but I don't really want to create a public function in dial.h that shouldn't exist. Once app_dial is using something else for the actual dial action, the version of this in app_dial shouldn't be needed.


> On April 1, 2013, 7:07 p.m., David Lee wrote:
> > /trunk/main/manager_channels.c, lines 288-289
> > <https://reviewboard.asterisk.org/r/2383/diff/6/?file=35141#file35141line288>
> >
> >     You shouldn't need both the suffix and the channel name. Just one should suffice.

I have mixed feelings about this. Say we have two channels, one with a suffix of 'Dest':

Channel: SIP/foo
ChannelDest: SIP/bar
Uniqueid: 1234
UniqueidDest: 5678
ChanVariable(SIP/foo): baz=shmackity
ChanVariable(SIP/bar): baz=yackity

While the suffix is not strictly necessary, the lack of the suffix certainly makes the syntax less consistent. Are we sure this is preferable?


- Matt


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


On March 31, 2013, 5:29 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2383/
> -----------------------------------------------------------
> 
> (Updated March 31, 2013, 5:29 p.m.)
> 
> 
> Review request for Asterisk Developers and David Lee.
> 
> 
> Bugs: ASTERISK-21196
>     https://issues.asterisk.org/jira/browse/ASTERISK-21196
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> As part of the CDR work for Asterisk 12 (see https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification), we need Dial information published over Stasis-Core. This patch refactors app_dial to publish the necessary events.
> 
> The Dial based events are slightly different in Asterisk 12 than in other previous versions:
>  * Dial is now two events, DialBegin and DialEnd. This matches the nomenclature of other AMI events. See https://wiki.asterisk.org/wiki/display/AST/AMI+1.4+Specification for more information.
>  * Dial events now occur at the beginning of a dial operation and when the status of the dial operation is known. Previously, it occurred on application exit, which occurred after bridging.
> 
> Note that other applications will need refactoring as well (such as the Dial Framework, Queue, FollowMe, etc.) - however, in order to limit the scope of the work, I've kept it only to app_dial at this point.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/manager_channels.c 384409 
>   /trunk/main/features.c 384409 
>   /trunk/main/dial.c 384409 
>   /trunk/main/channel_internal_api.c 384409 
>   /trunk/main/channel.c 384409 
>   /trunk/include/asterisk/stasis_channels.h PRE-CREATION 
>   /trunk/include/asterisk/channel.h 384409 
>   /trunk/apps/app_userevent.c 384409 
>   /trunk/apps/app_dial.c 384409 
>   /trunk/main/pbx.c 384409 
>   /trunk/main/stasis_channels.c PRE-CREATION 
>   /trunk/pbx/pbx_realtime.c 384409 
>   /trunk/tests/test_stasis_channels.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2383/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130402/fa15ef43/attachment-0001.htm>