Re: [asterisk-users] R2 error Seize Timeout
in your wanpipe.conf file change TE_SIG_MODE = CCS to TE_SIG_MODE = CAS Saludos/Regards - Gerardo Barajas ClearlyIP www.clearlyip.com On Tue, Mar 8, 2022 at 3:43 PM Duncan Turnbull wrote: > Hi Carlos > > On Wed, Mar 9, 2022 at 10:30 AM Carlos Chavez wrote: > >> The provider is the timing source. Both wanpipe1.conf and >> system.conf have the timing sources set to the remote side: >> >> TE_CLOCK = NORMAL >> >> Makes sense, I couldn't recall the options but this looks right > >> >> span=1,1,0,CAS,HDB3 >> >> I still have a feeling that the problem is on the providers side as >> during testing we never saw the issue. >> >> I have modified wanpipe1.conf to be CAS but the strange thing is >> that the freepbx gui does show CAS there but sets CCS on the >> configuration file. Now I have to wait and see if the problem persists. >> > > Technically CCS is usually for ISDN and wasn't always on timeslot 16, but > if it was working then perhaps it was good luck. How freepbx sets it is > another question though > > I am not sure what would go wrong on a provider side as they usually > standardise their systems. That said its always possible. > > Your error is a timeout in response to a line seize so either your > provider isn't seeing the signal, they aren't replying for some reason or > you aren't getting it back. That could fit with changes to the signalling > channel. Ideally if you can look at the signalling you can see whats > happening. I can't recall if asterisk will let you do that. CAS signalling > is very simple in that its just reflecting what used to be a physical > change for the line controls. Can you ask your providers to see what they > see or reset the trunk when the issue comes up to see if it matters > > Good luck > > >> On 08/03/22 11:54, Duncan Turnbull wrote: >> > It’s been a r we hike since we used these cards. This example may help >> > >> > >> https://wiki.freepbx.org/plugins/servlet/mobile?contentId=73007457#content/view/73007457 >> > >> > My thinking is it sounds like a timing error. Make sure your provider >> > is the timing source. Once it loses time you will get dropped calls >> > until it resyncs >> > >> > Good luck >> > >> > >> > >> >> On 9/03/2022, at 4:25 AM, Steinwendtner wrote: >> >> >> >> Hello, >> >> >> >> I must admit that I have never set up an asterisk system with R2 >> >> signalling. But from the config files >> >> >> >> point of view, you stated TE_SIG_MODE in wanpipe1.conf as ccs which >> >> should be cas, right ? >> >> >> >> If this does not help, you need to connect an external E1 Monitor. >> >> >> >> Regards, >> >> >> >> Hans >> >> >> >> Am 08.03.22 um 06:41 schrieb Carlos Chavez: >> >>> Last month we switched a Panasonic pbx with a Freepbx 16 >> >>> appliance. We use a single E1 in MFC/R2 (Mexico) with Telmex as a >> >>> provider. This was connected for a couple of days for testing with no >> >>> problems before the client moved offices to a new location. In the >> new >> >>> location we are now having a problem every few days where we get the >> >>> following error: >> >>> >> >>> [2022-03-07 07:30:11] ERROR[3469][C-004c] chan_dahdi.c: Chan 10 - >> >>> Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, >> MF >> >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> >>> [2022-03-07 07:30:44] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol >> >>> error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, >> MF >> >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> >>> [2022-03-07 07:32:15] ERROR[3704][C-004e] chan_dahdi.c: Chan 10 - >> >>> Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, >> MF >> >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> >>> [2022-03-07 07:32:52] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol >> >>> error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, >> MF >> >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> >>> >> >>> When we see that error the E1 will no longer send or receive >> >>> calls. Our solution has been to stop and restart Asterisk and >> >>> Wanconfig/Dahdi to restore service. Since restarting solves it I am >> >>> wondering if the problem is on my side and not on the providers. So >> far >> >>> it happens once or twice a week. When we report this to the provider >> >>> they simply state that the problem is on our side (it is their default >> >>> position) unless we can provide evidence to the contrary. Any >> >>> recommendations on how to debug this? >> >>> >> >>> Here is wanpipe1.conf: >> >>> [devices] >> >>> wanpipe1 = WAN_AFT_TE1, Comment >> >>> >> >>> [interfaces] >> >>> w1g1 = wanpipe1, , TDM_VOICE, Comment >> >>> >> >>> [wanpipe1] >> >>> CARD_TYPE = AFT >> >>> S514CPU = A >> >>> CommPort = PRI >> >>> AUTO_PCISLOT = NO >> >>> PCISLOT = 4 >> >>> PCIBUS = 8 >> >>> FE_MEDIA= E1 >> >>> FE_LCODE= HDB3 >> >>>
Re: [asterisk-users] R2 error Seize Timeout
Hi Carlos On Wed, Mar 9, 2022 at 10:30 AM Carlos Chavez wrote: > The provider is the timing source. Both wanpipe1.conf and > system.conf have the timing sources set to the remote side: > > TE_CLOCK = NORMAL > > Makes sense, I couldn't recall the options but this looks right > > span=1,1,0,CAS,HDB3 > > I still have a feeling that the problem is on the providers side as > during testing we never saw the issue. > > I have modified wanpipe1.conf to be CAS but the strange thing is > that the freepbx gui does show CAS there but sets CCS on the > configuration file. Now I have to wait and see if the problem persists. > Technically CCS is usually for ISDN and wasn't always on timeslot 16, but if it was working then perhaps it was good luck. How freepbx sets it is another question though I am not sure what would go wrong on a provider side as they usually standardise their systems. That said its always possible. Your error is a timeout in response to a line seize so either your provider isn't seeing the signal, they aren't replying for some reason or you aren't getting it back. That could fit with changes to the signalling channel. Ideally if you can look at the signalling you can see whats happening. I can't recall if asterisk will let you do that. CAS signalling is very simple in that its just reflecting what used to be a physical change for the line controls. Can you ask your providers to see what they see or reset the trunk when the issue comes up to see if it matters Good luck > On 08/03/22 11:54, Duncan Turnbull wrote: > > It’s been a r we hike since we used these cards. This example may help > > > > > https://wiki.freepbx.org/plugins/servlet/mobile?contentId=73007457#content/view/73007457 > > > > My thinking is it sounds like a timing error. Make sure your provider > > is the timing source. Once it loses time you will get dropped calls > > until it resyncs > > > > Good luck > > > > > > > >> On 9/03/2022, at 4:25 AM, Steinwendtner wrote: > >> > >> Hello, > >> > >> I must admit that I have never set up an asterisk system with R2 > >> signalling. But from the config files > >> > >> point of view, you stated TE_SIG_MODE in wanpipe1.conf as ccs which > >> should be cas, right ? > >> > >> If this does not help, you need to connect an external E1 Monitor. > >> > >> Regards, > >> > >> Hans > >> > >> Am 08.03.22 um 06:41 schrieb Carlos Chavez: > >>> Last month we switched a Panasonic pbx with a Freepbx 16 > >>> appliance. We use a single E1 in MFC/R2 (Mexico) with Telmex as a > >>> provider. This was connected for a couple of days for testing with no > >>> problems before the client moved offices to a new location. In the new > >>> location we are now having a problem every few days where we get the > >>> following error: > >>> > >>> [2022-03-07 07:30:11] ERROR[3469][C-004c] chan_dahdi.c: Chan 10 - > >>> Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, > MF > >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > >>> [2022-03-07 07:30:44] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol > >>> error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF > >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > >>> [2022-03-07 07:32:15] ERROR[3704][C-004e] chan_dahdi.c: Chan 10 - > >>> Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, > MF > >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > >>> [2022-03-07 07:32:52] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol > >>> error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF > >>> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > >>> > >>> When we see that error the E1 will no longer send or receive > >>> calls. Our solution has been to stop and restart Asterisk and > >>> Wanconfig/Dahdi to restore service. Since restarting solves it I am > >>> wondering if the problem is on my side and not on the providers. So > far > >>> it happens once or twice a week. When we report this to the provider > >>> they simply state that the problem is on our side (it is their default > >>> position) unless we can provide evidence to the contrary. Any > >>> recommendations on how to debug this? > >>> > >>> Here is wanpipe1.conf: > >>> [devices] > >>> wanpipe1 = WAN_AFT_TE1, Comment > >>> > >>> [interfaces] > >>> w1g1 = wanpipe1, , TDM_VOICE, Comment > >>> > >>> [wanpipe1] > >>> CARD_TYPE = AFT > >>> S514CPU = A > >>> CommPort = PRI > >>> AUTO_PCISLOT = NO > >>> PCISLOT = 4 > >>> PCIBUS = 8 > >>> FE_MEDIA= E1 > >>> FE_LCODE= HDB3 > >>> FE_FRAME= NCRC4 > >>> FE_LINE= 1 > >>> TE_CLOCK = NORMAL > >>> TE_REF_CLOCK= 0 > >>> TE_SIG_MODE = CCS > >>> TE_HIGHIMPEDANCE= NO > >>> TE_RX_SLEVEL= 430 > >>> HW_RJ45_PORT_MAP = DEFAULT > >>> LBO = 120OH > >>> FE_TXTRISTATE= NO > >>> MTU = 1500 > >>> UDPPORT= 9000 > >>> TTL= 255 >
Re: [asterisk-users] R2 error Seize Timeout
The provider is the timing source. Both wanpipe1.conf and system.conf have the timing sources set to the remote side: TE_CLOCK = NORMAL span=1,1,0,CAS,HDB3 I still have a feeling that the problem is on the providers side as during testing we never saw the issue. I have modified wanpipe1.conf to be CAS but the strange thing is that the freepbx gui does show CAS there but sets CCS on the configuration file. Now I have to wait and see if the problem persists. On 08/03/22 11:54, Duncan Turnbull wrote: It’s been a r we hike since we used these cards. This example may help https://wiki.freepbx.org/plugins/servlet/mobile?contentId=73007457#content/view/73007457 My thinking is it sounds like a timing error. Make sure your provider is the timing source. Once it loses time you will get dropped calls until it resyncs Good luck On 9/03/2022, at 4:25 AM, Steinwendtner wrote: Hello, I must admit that I have never set up an asterisk system with R2 signalling. But from the config files point of view, you stated TE_SIG_MODE in wanpipe1.conf as ccs which should be cas, right ? If this does not help, you need to connect an external E1 Monitor. Regards, Hans Am 08.03.22 um 06:41 schrieb Carlos Chavez: Last month we switched a Panasonic pbx with a Freepbx 16 appliance. We use a single E1 in MFC/R2 (Mexico) with Telmex as a provider. This was connected for a couple of days for testing with no problems before the client moved offices to a new location. In the new location we are now having a problem every few days where we get the following error: [2022-03-07 07:30:11] ERROR[3469][C-004c] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 [2022-03-07 07:30:44] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 [2022-03-07 07:32:15] ERROR[3704][C-004e] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 [2022-03-07 07:32:52] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 When we see that error the E1 will no longer send or receive calls. Our solution has been to stop and restart Asterisk and Wanconfig/Dahdi to restore service. Since restarting solves it I am wondering if the problem is on my side and not on the providers. So far it happens once or twice a week. When we report this to the provider they simply state that the problem is on our side (it is their default position) unless we can provide evidence to the contrary. Any recommendations on how to debug this? Here is wanpipe1.conf: [devices] wanpipe1 = WAN_AFT_TE1, Comment [interfaces] w1g1 = wanpipe1, , TDM_VOICE, Comment [wanpipe1] CARD_TYPE = AFT S514CPU = A CommPort = PRI AUTO_PCISLOT = NO PCISLOT = 4 PCIBUS = 8 FE_MEDIA = E1 FE_LCODE = HDB3 FE_FRAME = NCRC4 FE_LINE = 1 TE_CLOCK = NORMAL TE_REF_CLOCK = 0 TE_SIG_MODE = CCS TE_HIGHIMPEDANCE = NO TE_RX_SLEVEL = 430 HW_RJ45_PORT_MAP = DEFAULT LBO = 120OH FE_TXTRISTATE = NO MTU = 1500 UDPPORT = 9000 TTL = 255 IGNORE_FRONT_END = NO TDMV_SPAN = 1 TDMV_DCHAN = 16 TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS Blue Alarm and keep line down #wanpipemon -i w1g1 -c Ttx_ais_off to disable AIS maintenance mode #wanpipemon -i w1g1 -c Ttx_ais_on to enable AIS maintenance mode TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events from hardware HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation enabled with nlp (default) # OCT_SPEECH: improves software tone detection by disabling NLP (echo possible) # OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of incoming media (must have hwdtmf enabled) HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on the line - could break fax HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic echo cancelation HWEC_NLP_DISABLE = NO # NO: default YES: guarantees software tone detection (possible echo) HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal [w1g1] ACTIVE_CH
Re: [asterisk-users] R2 error Seize Timeout
It’s been a r we hike since we used these cards. This example may help https://wiki.freepbx.org/plugins/servlet/mobile?contentId=73007457#content/view/73007457 My thinking is it sounds like a timing error. Make sure your provider is the timing source. Once it loses time you will get dropped calls until it resyncs Good luck > On 9/03/2022, at 4:25 AM, Steinwendtner wrote: > > Hello, > > I must admit that I have never set up an asterisk system with R2 signalling. > But from the config files > > point of view, you stated TE_SIG_MODE in wanpipe1.conf as ccs which should be > cas, right ? > > If this does not help, you need to connect an external E1 Monitor. > > Regards, > > Hans > >> Am 08.03.22 um 06:41 schrieb Carlos Chavez: >> Last month we switched a Panasonic pbx with a Freepbx 16 >> appliance. We use a single E1 in MFC/R2 (Mexico) with Telmex as a >> provider. This was connected for a couple of days for testing with no >> problems before the client moved offices to a new location. In the new >> location we are now having a problem every few days where we get the >> following error: >> >> [2022-03-07 07:30:11] ERROR[3469][C-004c] chan_dahdi.c: Chan 10 - >> Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF >> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> [2022-03-07 07:30:44] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol >> error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF >> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> [2022-03-07 07:32:15] ERROR[3704][C-004e] chan_dahdi.c: Chan 10 - >> Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF >> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> [2022-03-07 07:32:52] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol >> error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF >> state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 >> >> When we see that error the E1 will no longer send or receive >> calls. Our solution has been to stop and restart Asterisk and >> Wanconfig/Dahdi to restore service. Since restarting solves it I am >> wondering if the problem is on my side and not on the providers. So far >> it happens once or twice a week. When we report this to the provider >> they simply state that the problem is on our side (it is their default >> position) unless we can provide evidence to the contrary. Any >> recommendations on how to debug this? >> >> Here is wanpipe1.conf: >> [devices] >> wanpipe1 = WAN_AFT_TE1, Comment >> >> [interfaces] >> w1g1 = wanpipe1, , TDM_VOICE, Comment >> >> [wanpipe1] >> CARD_TYPE = AFT >> S514CPU = A >> CommPort = PRI >> AUTO_PCISLOT = NO >> PCISLOT = 4 >> PCIBUS = 8 >> FE_MEDIA= E1 >> FE_LCODE= HDB3 >> FE_FRAME= NCRC4 >> FE_LINE= 1 >> TE_CLOCK = NORMAL >> TE_REF_CLOCK= 0 >> TE_SIG_MODE = CCS >> TE_HIGHIMPEDANCE= NO >> TE_RX_SLEVEL= 430 >> HW_RJ45_PORT_MAP = DEFAULT >> LBO = 120OH >> FE_TXTRISTATE= NO >> MTU = 1500 >> UDPPORT= 9000 >> TTL= 255 >> IGNORE_FRONT_END= NO >> TDMV_SPAN= 1 >> TDMV_DCHAN= 16 >> TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS >> Blue Alarm and keep line down >> #wanpipemon -i w1g1 -c Ttx_ais_off to >> disable AIS maintenance mode >> #wanpipemon -i w1g1 -c Ttx_ais_on to >> enable AIS maintenance mode >> TDMV_HW_DTMF= NO# YES: receive dtmf events from hardware >> TDMV_HW_FAX_DETECT= NO# YES: receive fax 1100hz events >> from hardware >> HWEC_OPERATION_MODE = OCT_NORMAL# OCT_NORMAL: echo cancelation >> enabled with nlp (default) >> # OCT_SPEECH: improves software >> tone detection by disabling NLP (echo possible) >> # OCT_NO_ECHO:disables echo >> cancelation but allows VQE/tone functions. >> HWEC_DTMF_REMOVAL = NO# NO: default YES: remove dtmf out of >> incoming media (must have hwdtmf enabled) >> HWEC_NOISE_REDUCTION= NO# NO: default YES: reduces noise on the >> line - could break fax >> HWEC_ACUSTIC_ECHO = NO# NO: default YES: enables acustic echo >> cancelation >> HWEC_NLP_DISABLE= NO# NO: default YES: guarantees software >> tone detection (possible echo) >> HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio >> level to be maintained (-20 default) >> HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio >> level to be maintained (-20 default) >> HWEC_TX_GAIN= 0# 0: disable -24-24: db values to >> be applied to tx signal >> HWEC_RX_GAIN= 0# 0: disable -24-24: db values to >> be applied to tx signal >> >> [w1g1] >> ACTIVE_CH= ALL >> TDMV_HWEC= NO >> MTU = 8 >>
Re: [asterisk-users] R2 error Seize Timeout
Hello, I must admit that I have never set up an asterisk system with R2 signalling. But from the config files point of view, you stated TE_SIG_MODE in wanpipe1.conf as ccs which should be cas, right ? If this does not help, you need to connect an external E1 Monitor. Regards, Hans Am 08.03.22 um 06:41 schrieb Carlos Chavez: > Last month we switched a Panasonic pbx with a Freepbx 16 > appliance. We use a single E1 in MFC/R2 (Mexico) with Telmex as a > provider. This was connected for a couple of days for testing with no > problems before the client moved offices to a new location. In the new > location we are now having a problem every few days where we get the > following error: > > [2022-03-07 07:30:11] ERROR[3469][C-004c] chan_dahdi.c: Chan 10 - > Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF > state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > [2022-03-07 07:30:44] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol > error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF > state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > [2022-03-07 07:32:15] ERROR[3704][C-004e] chan_dahdi.c: Chan 10 - > Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF > state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > [2022-03-07 07:32:52] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol > error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF > state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 > > When we see that error the E1 will no longer send or receive > calls. Our solution has been to stop and restart Asterisk and > Wanconfig/Dahdi to restore service. Since restarting solves it I am > wondering if the problem is on my side and not on the providers. So far > it happens once or twice a week. When we report this to the provider > they simply state that the problem is on our side (it is their default > position) unless we can provide evidence to the contrary. Any > recommendations on how to debug this? > > Here is wanpipe1.conf: > [devices] > wanpipe1 = WAN_AFT_TE1, Comment > > [interfaces] > w1g1 = wanpipe1, , TDM_VOICE, Comment > > [wanpipe1] > CARD_TYPE = AFT > S514CPU = A > CommPort = PRI > AUTO_PCISLOT = NO > PCISLOT = 4 > PCIBUS = 8 > FE_MEDIA = E1 > FE_LCODE = HDB3 > FE_FRAME = NCRC4 > FE_LINE = 1 > TE_CLOCK = NORMAL > TE_REF_CLOCK = 0 > TE_SIG_MODE = CCS > TE_HIGHIMPEDANCE = NO > TE_RX_SLEVEL = 430 > HW_RJ45_PORT_MAP = DEFAULT > LBO = 120OH > FE_TXTRISTATE = NO > MTU = 1500 > UDPPORT = 9000 > TTL = 255 > IGNORE_FRONT_END = NO > TDMV_SPAN = 1 > TDMV_DCHAN = 16 > TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS > Blue Alarm and keep line down > #wanpipemon -i w1g1 -c Ttx_ais_off to > disable AIS maintenance mode > #wanpipemon -i w1g1 -c Ttx_ais_on to > enable AIS maintenance mode > TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware > TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events > from hardware > HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation > enabled with nlp (default) > # OCT_SPEECH: improves software > tone detection by disabling NLP (echo possible) > # OCT_NO_ECHO:disables echo > cancelation but allows VQE/tone functions. > HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of > incoming media (must have hwdtmf enabled) > HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on the > line - could break fax > HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic echo > cancelation > HWEC_NLP_DISABLE = NO # NO: default YES: guarantees software > tone detection (possible echo) > HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio > level to be maintained (-20 default) > HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio > level to be maintained (-20 default) > HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to > be applied to tx signal > HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to > be applied to tx signal > > [w1g1] > ACTIVE_CH = ALL > TDMV_HWEC = NO > MTU = 8 > > Here is system.conf > > span=1,1,0,CAS,HDB3 > cas=1-10,11-15,17-31:1101 > echocanceller=oslec,1-10,11-15,17-31 > loadzone=mx > defaultzone=mx > > Here is chan_dahdi.conf > > signalling=mfcr2 > mfcr2_variant=mx > mfcr2_get_ani_first=no > mfcr2_max_ani=10 > mfcr2_max_dnis=4 > mfcr2_category=national_priority_subscriber > mfcr2_call_files=no > mfcr2_mfback_timeout=-1 > mfcr2_metering_pulse_timeout=-1 > mfcr2_allow_collect_calls=yes > mfcr2_double_answer=no > mfcr2_immediate_accept=no >
[asterisk-users] R2 error Seize Timeout
Last month we switched a Panasonic pbx with a Freepbx 16 appliance. We use a single E1 in MFC/R2 (Mexico) with Telmex as a provider. This was connected for a couple of days for testing with no problems before the client moved offices to a new location. In the new location we are now having a problem every few days where we get the following error: [2022-03-07 07:30:11] ERROR[3469][C-004c] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 [2022-03-07 07:30:44] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 [2022-03-07 07:32:15] ERROR[3704][C-004e] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 [2022-03-07 07:32:52] ERROR[29573] chan_dahdi.c: Chan 10 - Protocol error. Reason = Seize Timeout, R2 State = Clear Forward Transmitted, MF state = MF Engine Off, MF Group = Forward MF init, CAS = 0x08 When we see that error the E1 will no longer send or receive calls. Our solution has been to stop and restart Asterisk and Wanconfig/Dahdi to restore service. Since restarting solves it I am wondering if the problem is on my side and not on the providers. So far it happens once or twice a week. When we report this to the provider they simply state that the problem is on our side (it is their default position) unless we can provide evidence to the contrary. Any recommendations on how to debug this? Here is wanpipe1.conf: [devices] wanpipe1 = WAN_AFT_TE1, Comment [interfaces] w1g1 = wanpipe1, , TDM_VOICE, Comment [wanpipe1] CARD_TYPE = AFT S514CPU = A CommPort = PRI AUTO_PCISLOT = NO PCISLOT = 4 PCIBUS = 8 FE_MEDIA = E1 FE_LCODE = HDB3 FE_FRAME = NCRC4 FE_LINE = 1 TE_CLOCK = NORMAL TE_REF_CLOCK = 0 TE_SIG_MODE = CCS TE_HIGHIMPEDANCE = NO TE_RX_SLEVEL = 430 HW_RJ45_PORT_MAP = DEFAULT LBO = 120OH FE_TXTRISTATE = NO MTU = 1500 UDPPORT = 9000 TTL = 255 IGNORE_FRONT_END = NO TDMV_SPAN = 1 TDMV_DCHAN = 16 TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS Blue Alarm and keep line down #wanpipemon -i w1g1 -c Ttx_ais_off to disable AIS maintenance mode #wanpipemon -i w1g1 -c Ttx_ais_on to enable AIS maintenance mode TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events from hardware HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation enabled with nlp (default) # OCT_SPEECH: improves software tone detection by disabling NLP (echo possible) # OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of incoming media (must have hwdtmf enabled) HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on the line - could break fax HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic echo cancelation HWEC_NLP_DISABLE = NO # NO: default YES: guarantees software tone detection (possible echo) HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal [w1g1] ACTIVE_CH = ALL TDMV_HWEC = NO MTU = 8 Here is system.conf span=1,1,0,CAS,HDB3 cas=1-10,11-15,17-31:1101 echocanceller=oslec,1-10,11-15,17-31 loadzone=mx defaultzone=mx Here is chan_dahdi.conf signalling=mfcr2 mfcr2_variant=mx mfcr2_get_ani_first=no mfcr2_max_ani=10 mfcr2_max_dnis=4 mfcr2_category=national_priority_subscriber mfcr2_call_files=no mfcr2_mfback_timeout=-1 mfcr2_metering_pulse_timeout=-1 mfcr2_allow_collect_calls=yes mfcr2_double_answer=no mfcr2_immediate_accept=no mfcr2_accept_on_offer=yes mfcr2_skip_category=no mfcr2_forced_release=no mfcr2_charge_calls=yes group=0 context=from-digital channel=>1-10 -- Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez +52 (55)8116-9161 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started
