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

[KNK]

> On Aug. 31, 2012, 3:18 p.m., rmudgett wrote:
> > I also committed the SS7-27_libss7_trunk2_v2.diff for libss7 that fixes the GRS message loop.
> > 
> > The trunk libss7 has become chatty with all the unconditional timer start/stop messages.  There are many other new ss7_message() calls that are not conditional on debug output being turned on.  I expect a subsequent patch will quiet these messages.
> > 
> > We're getting closer. :-)

SS7-27_libss7_trunk2_v3.diff in the issue makes all timer related messages debug messages.
I am not sure if all "Got XXX, but ..." in isup_receive() should be changed too, because they show an unexpected messages - not touched


> On Aug. 31, 2012, 3:18 p.m., rmudgett wrote:
> > trunk/configs/ss7.timers.sample, line 41
> > <https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41>
> >
> >     I cannot find the definition for this timer in ITU.  It is really the overlap digit timeout and must always be defined (Even for ANSI).
> >     
> >     If your dialplan has extension 100 and extension 1000 and an incoming call calls 100, then the call will not go through and the channel will get stuck in the allocated state. (p->call_level = SIG_SS7_CALL_LEVEL_ALLOCATED)
> >     
> >     Also if the incoming call hangs up before this timer expires, the channel will be stuck because the call was never passed to Asterisk core.
> >     
> >     Another incoming call on this circuit will clear this stuck condition if it gets passed to the Asterisk core.  However, it will have an assertion failure in the IAM processing about the channel not being idle.
> >     ast_assert(!p->owner && p->call_level == SIG_SS7_CALL_LEVEL_IDLE)

ITU-T Q.764 2.1.2.1 d) and 2.1.4.8 e) then 4-6sec timer value defined in table A.1 and we should send ACM on expire, but in ANSI T1.113 there is a Note that 'Timer is not specified for U. S. networks.'

So the assert should be changed to pass both states SIG_SS7_CALL_LEVEL_IDLE and SIG_SS7_CALL_LEVEL_ALLOCATED or i misunderstood?


- KNK


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


On Aug. 31, 2012, 10:36 a.m., KNK wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1676/
> -----------------------------------------------------------
> 
> (Updated Aug. 31, 2012, 10:36 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 372115 
>   trunk/channels/sig_ss7.h 372115 
>   trunk/channels/sig_ss7.c 372115 
>   trunk/configs/chan_dahdi.conf.sample 372115 
>   trunk/configs/ss7.timers.sample PRE-CREATION 
>   trunk/configure.ac 372115 
> 
> Diff: https://reviewboard.asterisk.org/r/1676/diff
> 
> 
> Testing
> -------
> 
> compiles, link setup, cli commands, bassic calls, connected line and redirection.
> 
> 
> Thanks,
> 
> KNK
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120903/9ef22cbf/attachment.htm>