[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?
>
> 
> rmudgett wrote:
>     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.
>
> 
> KNK wrote:
>     1) About T10 - the original code had it as DIGITTIMEOUT timer used for both ITU and ANSI. As T10 on my understanding has the similar functionality i have renamed it to T10 which led to the confusion, because T10 is not defined for ANSI ... after digging (googling) a bit more i've found that 'In North America, enbloc signaling is always used', so it is OK to leave it as T10 and will fix ss7_match_extension() to send REL if T10 is not defined or ANSI (just to be safe) ... isup_start_digittimeout() in libss7 should be changed to non-void.
>     Actually libss7 is unable to use overlap dialing out and i have not tested dialing in too - that functionality deserves some attention later.
>     
>     2) the code removed after v6 https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461, should be restored then - dropping both calls is the only way out of this situation as we do not have an isup_call yet and no way to inform libss7
> 
> KNK wrote:
>     Just an idea about 2) ... what if we do the opposite i.e. add a callback in Asterisk, so libss7 can check for dual seizure from isup_event_iam(). The callback can then simply check for call_level == SIG_SS7_CALL_LEVEL_IDLE
> 
> rmudgett wrote:
>     2) Yes.  I think that would be best.  The architecture of chan_dahdi handles glare poorly for anything but analog.  The problem is mainly because chan_dahdi assigns the media to the call before the channel protocols have a chance to negotiate for it.

My last comment was before your callback idea.  My preliminary idea was to move the calls to isup_new_call() and isup_init_call() in sig_ss7_call() to sig_ss7_available() and then indicate to libss7 that a call was pending that way libss7 would know about the call earlier.  The isup_new_call() and isup_init_call() call are really allocation resource related and not call initiation.  Unfortunately, doing that would also cause many other change ripples.

The isup_event_iam() already has a callback doing essentially that.  libss7 just needs to know about the pending call.


- 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/20120905/682e78d3/attachment.htm>