[asterisk-users] R2 error Seize Timeout
Gerardo Barajas
jerry.barajas at gmail.com
Tue Mar 8 16:20:30 CST 2022
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 <duncan at turnbull.co.nz>
wrote:
> Hi Carlos
>
> On Wed, Mar 9, 2022 at 10:30 AM Carlos Chavez <cursor at telecomab.mx> 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 <steinwendtner at gmx.net> 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-0000004c] 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-0000004e] 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
>> >>>
>> >>
>> >> --
>> >> _____________________________________________________________________
>> >> -- 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
>> >>
>> >> asterisk-users mailing list
>> >> To UNSUBSCRIBE or update options visit:
>> >> http://lists.digium.com/mailman/listinfo/asterisk-users
>> >
>> --
>> 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
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _____________________________________________________________________
> -- 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
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20220308/be9467dd/attachment.html>
More information about the asterisk-users
mailing list