[asterisk-dev] [Code Review]: Changes from Mantis ID 13495 in trunk.

KNK reviewboard at asterisk.org
Wed Mar 21 07:17:33 CDT 2012



> On March 8, 2012, 4:22 p.m., rmudgett wrote:
> > trunk/channels/sig_ss7.c, lines 2593-2610
> > <https://reviewboard.asterisk.org/r/1676/diff/2/?file=23474#file23474line2593>
> >
> >     This information should be obtained from the sig_ss7_indicate():AST_CONTROL_CONNECTED_LINE and ast_channel.connected.id.  Dialplan accesses these values using the CONNECTEDLINE function.  Continuing to add SS7 specific channel variables is not recommended.  See sig_pri for usage.

Moved connected line update from sig_ss7_answer to sig_ss7_indicate and replaced the variable with ast_channel_connected()


> On March 8, 2012, 4:22 p.m., rmudgett wrote:
> > trunk/channels/sig_ss7.h, lines 221-228
> > <https://reviewboard.asterisk.org/r/1676/diff/2/?file=23473#file23473line221>
> >
> >     This redirecting information should also be put into the ast_channel.redirecting.from structure.  The redirecting information is accessed by the REDIRECTING dialplan function.  Other channel technologies (SIP and ISDN) use the ast_channel.redirecting information instead of channel variables.
> >     
> >     Outgoing calls should prefer the data in the ast_channel.redirecting.from structure instead of the SS7 channel technology specific channel variable.

I am having some problems with this change:
1. REDIRECTING dialplan function sets ast_channel.redirecting.from and ast_channel.redirecting.to only, while for SS7 there is also the original from. Should the function be extended with orig_from ast_party_id and orig_reason or we should store only the last from and use SS7 specific variables for the orig_*
2. There are two redirect counters and info_indication, which should also go in ast_party_redirecting?
3. How the indication info should be translated from/to XXX-num-pres?

I think we should store only the from and to numbers for the other channels (if redirection information presentation is not restricted) and presentation to allowed/restricted (from indication info), use the highest redirect counter (they should be equal), but keep the specific variables.
For outgoing calls: parse redirecting data only if SS7_REDIRECT_INFO_IND is defined and also keep SS7_REDIRECT_INFO_ORIG_REAS specific variable. If SS7_REDIRECT_INFO_IND is set to allowed it may be changed to restricted based on the from/to presentation or force the provided value.


- KNK


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


On March 21, 2012, 5:14 a.m., KNK wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1676/
> -----------------------------------------------------------
> 
> (Updated March 21, 2012, 5:14 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> chan_dahdi / sig_ss7 part of changes
> 
> 
> This addresses bug SS7-27.
>     https://issues.asterisk.org/jira/browse/SS7-27
> 
> 
> Diffs
> -----
> 
>   trunk/channels/chan_dahdi.c 358623 
>   trunk/channels/sig_ss7.h 358623 
>   trunk/channels/sig_ss7.c 358623 
> 
> Diff: https://reviewboard.asterisk.org/r/1676/diff
> 
> 
> Testing
> -------
> 
> compiles, link setup, cli commands, bassic calls
> Passed my phone calls through local SS7 loop for few days without problems
> 
> 
> Thanks,
> 
> KNK
> 
>

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


More information about the asterisk-dev mailing list