Summary:	ASTERISK-02689: [patch] CLI command 'pri restart span <spannum>'
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2004-10-27 11:43:08	Date Closed:	2011-06-07 14:05:24
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20041027__pri_restart.diff.txt
Description:	Used to restart a span when the channels aren't responding, and the normally timed restart events haven't fired yet.
Comments:	By: Brian West (bkw918) 2004-11-05 14:54:12.000-0600 Also: stop gracefully restart gracefully both do not function correctly when using PRI.  They should busy out all the B channels but NOT return busy so it can continue on to the next T1 on the next box.  But currently it doesn't behave that way.  Just asking here to see what you think/know about this Corydon! bkw By: Paul Cadach (pcadach) 2004-11-05 22:17:14.000-0600 I have analogues patch too but isn't publish because its violates specifications: RESTART message must not be sent over the link until you don't receive RESTART ACK from previous RESTART message. In two words, you souldn't flood link with RESTART messages, and must send them sequentially, one after one is acknoweleged... By: Tilghman Lesher (tilghman) 2004-11-05 23:09:38.000-0600 I don't see where in the specification that RESTART is limited in that way.  RESTART ACK is only to indicate that a RESTART has been received from the remote end.  Nowhere do I see that you may not send multiple RESTARTs. By: Tilghman Lesher (tilghman) 2004-11-05 23:23:33.000-0600 In fact, 5.5.1 specifies explicitly that you MAY send more than one RESTART without receiving a corresponding ACK: "If a RESTART ACKNOWLEDGE message is not received prior to the expiry of time T316, one or more subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message is returned," though it goes on to say that "A network shall limit the number of consecutive unsuccessful restart attempts to a default limit of two. . .An indication will be provided to the appropriate maintenance entity." As the command line restart is not invoked automatically, but only by the operator, it falls under maintenance action and is therefore permitted under the standard. By: Paul Cadach (pcadach) 2004-11-05 23:41:22.000-0600 An example - Alcatel S-12 randomly drops flooded RESTART messages, but Huawei's C&C08 works well. Because drops are possible you cannot be sure all channels resetted by issueing "pri restart span <x>", and no knowelege is sequentially issued restarts will reset ALL channels (i.e. exchange could drop RESTARTs for the same channels as for previously submitted pack of RESTARTs). So, some sort of serialization is required. By: Mark Spencer (markster) 2004-11-07 19:03:06.000-0600 The existing code for restarting works.  I would like some sort of "pri history" similar to the "sip history" to find out what is happening to create this unusual state. By: Paul Cadach (pcadach) 2004-11-09 15:31:37.000-0600 Citate from ETSI EN 300 403-1 document: "Upon transmitting the RESTART message the sender shall enter the Restart Request state REST 1, start timer T316, and wait for a RESTART ACKNOWLEDGE message. Also, no further RESTART messages shall be sent until a RESTART ACKNOWLEDGE message is received or timer T316 expires." As I understand, this paragraph FORBIDS to send other restarts until previous one is acknoweleged or expired. By: Tilghman Lesher (tilghman) 2004-11-09 16:30:13.000-0600 So you're not actually arguing against this command per se, only that we should be checking the timer T316 to ensure it has not already expired before taking action?  I can live with that. By: twisted (twisted) 2004-12-01 00:40:08.000-0600 Where does this sit?  Something that is still interested in? By: Tilghman Lesher (tilghman) 2004-12-01 10:27:01.000-0600 Closed pending implementation of the T316 timer.