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

[KNK]

> On Aug. 30, 2012, 1:27 p.m., rmudgett wrote:
> > I have committed Diff 13 plus fixing the finding in handle_ss7_linkset_mng() to the ss7_27_knk branch.
> > 
> > However, even with the SS7-27_libss7_trunk2_v1.diff patch from SS7-27 applied to libss7 I am still getting the message loop.  You should to setup the local DAHDI spans to replicate.  I described how to do that when I initially reported the problem.  Local DAHDI spans do not need any hardware.
> > 
> > I am concerned that the libss7 trunk code is now including non-call related status information in the struct isup_call.  The struct seems to be more like it should be called isup_circuit and thus should never be released unless the circuit is no longer provisioned.  The got_sent_msg and timer[] members are the principle reasons that isup_call is no longer call related but circuit related.
> >
> 
> KNK wrote:
>     Yes i am testing this with two local spans (dynamic=loc,1:0,31,0 and dynamic=loc,1:1,31,0). My initial setup was with 6 timeslots per span (6 being the signaling and 5 CICs). Later i have tested with 24 timeslots (T1) and 31 (E1) with signalling on 1 and 16, CICs in a row (cicbeginswitch=1 only) and in two separate groups (cicgeinswitch 1 and 17 skipping 16 as signaling) ... over 50 restarts without causing a message loop even once.
>     
>     I do not quite agree with isup_circuit and not releasing the call - it's more like 'events sequence' than call or circuit and applies to both ... but will think a bit more on this
> 
> rmudgett wrote:
>     I found that the loop happens if I have
>     ss7type=ansi
>     It does not happen if I have
>     ss7type=itu

Thank you!
isup.c around line 4338 "T1.113 requires sending GRS twice", so the second one is unexpected. I will see how it can be fixed, but most likely "Take independent action on every Circuit Group Reset Message received" instead of introducing T(RGS) 5sec timer as per T1.113 2.9.3.2
Before fixing this i will check where our ISUP_SENT_RSC is lost which will still cause the loop in the first place


- KNK


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


On Aug. 20, 2012, 6:35 a.m., KNK wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1676/
> -----------------------------------------------------------
> 
> (Updated Aug. 20, 2012, 6:35 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 371534 
>   trunk/channels/sig_ss7.h 371534 
>   trunk/channels/sig_ss7.c 371534 
>   trunk/configs/chan_dahdi.conf.sample 371534 
>   trunk/configs/ss7.timers.sample PRE-CREATION 
>   trunk/configure.ac 371534 
> 
> 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/20120831/a8c6feb2/attachment.htm>