[asterisk-bugs] [JIRA] (PRI-165) Need to respond to the MDL messages in point-to-point mode.

Thu Apr 24 09:00:18 CDT 2014

    [ https://issues.asterisk.org/jira/browse/PRI-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217559#comment-217559 ] 

Denis Alberto Martinez edited comment on PRI-165 at 4/24/14 8:59 AM:
---------------------------------------------------------------------

Customer feedback

Hi,

I was able to test the patch this morning. (same server as for issue #0036189)

Attached, you'll find :
- autosupport file,
- log for tests from yesterday
- log for tests from today *with* patch

You'll find the DAHDI configuration in the autosupport file : the BRI  port are configured in PTP.

_* Here are the tests done __yesterday__, __*without*__the patch :_

_Test1 :
_Conf changes :
layer2_persistence = keep_up

Tests :
- outgoing : 1/1 OK
- incoming : 1/3 OK

_Test2 :_
Conf changes :
layer1_presence = ignore
layer2_persistence = leave_down

Tests :
- outgoing : 2/2 OK
- incoming : 2/6 OK

_Test3 :_
Conf changes :
layer1_presence = ignore
layer2_persistence = leave_down
pritimer = n200,10

Tests :
- outgoing : 0/3 OK
- incoming : 2/6 but no sound when answering

Notes :
- the customer has 3 BRI lines and only 1 was OK (dahdi show status) 
after an asterisk + dahdi restart (span 1).
- these tests were done _*without*_ the patch

_* Here are the tests done today__, __*with*__the patch :_

_Test 4 :_
Conf :
layer1_presence = ignore
layer2_persistence = leave_down

_Test flow :_
Before applying the patch, no SPAN is OK, can't do outgoing nor incoming 
calls,
1- 09:05:00 - Unplug the 3 SPAN on asterisk and operator side,
2- 09:15:00 - Plug first SPAN asterisk and operator side,
=> The SPAN does not goes UP, chan_dahdi sends SABME message (but 
L1 is not UP then ...)
3- 09:17:42 - An incoming call comes
=> L1 goes UP, SPAN goes UP and becomes OK
4- 09:17:42 - 09:20:00 - Several tests :
=> Outgoing and incoming calls are OK on SPAN 1

5- 09:27:00 - Plug second SPAN asterisk and operator side,
=> The SPAN does not goes UP, chan_dahdi sends SABME message (but 
L1 is not UP then ...)
6- 09:28:45 - Send an outgoing call to saturate the second SPAN (Call-id 
: C-0000000c)
=> Call OK, we have two calls on SPAN 1
7- 09:29:57 - Send an outgoing call to try UP second SPAN (Call-id : 
C-0000000e)
=> It does not work, on SPAN1 : ok since there are already 2 calls,
=> It does not work, on SPAN2 : chan_dahdi doesn't seem to try this 
SPAN either ; indeed it is RED but the option layer1_presence)ignore 
says "Ignore alarms from DAHDI about this span. (Layer 1 and 2 will be 
brought back up for an outgoing call.)"
8- 09:30:25 - We send an incoming call to try UP second SPAN (Call-id : 
C-00000010)
=> It does work, L1 is brought UP at 09:30:24

9- Same kind of test with SPAN 3

_Conclusion :_
One problem met : the SPAN is not brought back up by an outgoing call 
(it was one of the problem noticed without the patch).
During the few tests I made today, it seems that it is OK.
Now we have to see if it stays on the long run.

========= Second email ========= 

I made other tests today.

The behavior of the system *with* the patch was OK during 24 hours. No difficulty were detected by the customer. I do not see problems in  the log either.

_*Test A :*_
See attached file :
20140424-asterisk-l1ignore-l2leave_down-withoutpatch.log.gz
20140424-asterisk-dahdishowstatus-withoutpatch.log.gz (result of dahdi 
show status every minute)

I re-installed the non-patched libpri without changing the configuration  and made some tests. It reveals that without the patch, the system does not behave correctly.  Particularly the second span never went up again. All incoming calls sent by the operator on this span failed. chan_dahdi didn't try to UP the span when you issue an outgoing call on 
this span 

Note :
- incoming calls were sent at 11:06:05, 11:06:20, 11:07:20, 11:07:46, 
11:08:10
- outgoing calls were issued at 11:14:51 (ok span 1), 11:15:40 (ok span 3)

_*Test B :*_
See attached file :
20140424-asterisk-l1ignore-l2leave_down-withpatch.log.gz
20140424-asterisk-dahdishowstatus-withpatch.log.gz (result of dahdi show 
status every minute)

Since it didn't work, I re-installed the patched libpri and restarted 
the services.
With only a dahdi + asterisk restart, the service never came back.
No incoming calls on span 2, span 2 stays RED.

See log from 11:17:00 to 11:40:00.

I then asked the customer to unplug the BRI lines at the operator side 
and to plug them back.
See log :
- 11:42:44 - span 1 replugged
- 11:47:20 - span 2 replugged (was incorrectly plugged at 11:45:11)
- 11:48:20 - span 3 replugged

After having unplug and replug the SPAN, all SPAN were OK but no  incoming and no outgoing calls were possible.
See log from 11:48:00 -> 11:54:00.

I then restarted asterisk : incoming calls were now possible (first restart at 11:54:14 - with option pritimer = n200,10 but 
probably without effect - and second restart at 11:55:04 without the  pritimer option).

_*My 'conclusions' are :*_
The patch seems to make the system more stable when the system is working. But, if the system becomes unstable, the patch doesn't permit to recover  normal operation (which is coherent with what you hint that is that  there is a second problem with L1 establishment/negotiation). 

Then I'm also still puzzled with chan_dahdi/dahdi behavior in l1ignore 
and l2leave_down mode since :
- L2 is always up
- chan_dahdi doesn't seem to UP L1/L2 when you try to issue an outgoing 
call on a RED SPAN.

was (Author: dmartinez):
Customer feedback