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

[rmudgett]

> 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)
> 
> KNK wrote:
>     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?
>

There are two issues here:

1) I take it the SAM message is not supported by ANSI since T10 is not specified.  With no T10 specified, then ss7_match_extension() should be changed to not call isup_start_digittimeout() if configured for ANSI since that timer is not specified for US networks.  The called number must either match or not match an extension.

2) There is a glare problem at the root of this assertion failure.  It is not easy to explain because it involves a long chain of events.  Since libss7 now handles glare resolution, libss7 needs to be informed about a pending outgoing call when chan_dahdi allocates a channel for it.

ast_request() allocates resources for an outgoing call.
ast_call() initiates the outgoing call.
ast_hangup() can be called on a channel at any time after ast_request() to destroy the created channel.

Currently libss7 doesn't know about a pending outgoing call until the ast_call() happens.  If an incoming call happens between the ast_request() and the ast_call(), the glare is not handled and the two calls step on each other.


- rmudgett


-----------------------------------------------------------
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/20120904/a7f1e891/attachment-0001.htm>