[asterisk-bugs] [JIRA] (PRI-157) late PRI_EVENT_CONNECT_ACK on multiple BRI lines in PTP

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on PRI-157:
-------------------------------------

The window shut message is normal and not an error since the default window size on BRI is 1 (K=1).

The window is shut because the PROCEEDING message has not been acknowledged by the network by the time the CONNECT is sent.  In fact the PROCEEDING message has to be retransmitted because the network did not respond to it the first time.  Since the network is either not expecting the PROCEEDING message to come in so quickly or is really slow to process the PROCEEDING message, I suggest adding a Wait(2) before answering the call to compensate.

                
> late PRI_EVENT_CONNECT_ACK on multiple BRI lines in PTP
> -------------------------------------------------------
>
>                 Key: PRI-157
>                 URL: https://issues.asterisk.org/jira/browse/PRI-157
>             Project: LibPRI
>          Issue Type: Bug
>      Security Level: None
>         Environment: Elastix 2.4 64bits
> kernel: 2.6.18-348.1.1.el5
> asterisk: 1.8.20.0
> libpri: 1.4.14
> dahdi: 2.6.1
> hardware: Sangoma A500 in CPE mode
> lines: 2-6 BRI lines in PTP (Switzerland)
>            Reporter: Nicolas Ouedraogo
>            Assignee: Richard Mudgett
>            Severity: Critical
>         Attachments: BRI_late_CONNECT_ACK.txt
>
>
> Hello!
> I have a strange problem with BRI lines in PTP : when a call comes in, Asterisk answers and play a message, but the line is effectively answered *after* the Playback() has started.
> 'pri show debug' shows that the PRI_EVENT_CONNECT_ACK comes in late, after an error: "PRI Span: 1 TEI=0 Couldn't transmit I-frame at this time due to window shut".
> The effect is that the caller does not hear the first 1-2 seconds of the message played (same behavior when the call is directly answered by a SIP phone instead of a Playback() message).
> This behaviour seems to happen only with Elastix 2.3/2.4 (in 64bits mode, not tested in 32bits) where the sangoma A500 is configured with DAHDI, and on sites which have 2 or more BRI lines in PTP mode.
> Here's what I've tested so far :
> - customer A has 2 BRI lines in PTP mode. I replaced an old PBX by an Asterisk box (Dell R210, Elastix 2.4 in 64bits, sangoma A500, wanpipe 7.0.0, DAHDI). The problem occurs immediately and systematically, there was no such problem with the old PBX AFAIK.
> - customer B has 6 BRI lines in PTP. We already have an Asterisk box there (Dell R2xx, Elastix 1.3 32bits, sangoma A500, wanpipe 3.5.14, chan_woomera is used, not DAHDI), no problems. I upgraded the system to Elastix 2.4-64bits, the problem occurs, so I reverted back to the old Elastix 1.3
> - I have tested Elastix 2.4-64bits at our office on a single BRI line PTMP, no problem.
> The Elastix installs are stock distributions, with yum update applied.
> I will attach a log of an incoming call with 'pri set debug 2'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira