[asterisk-r2] Protocol error

[Anton Krall]

Funny thing.. I got this error before (this morning)

chan-1-forward-59-20090617112201.call:[11:22:12:761] [Thread: 16169888]
[Chan 1] - Protocol error. Reason = Forward Safety Timeout, R2 State = Seize
ACK Re
ceived, MF state = Waiting Far End Timeout, MF Group = Forward Group I, CAS
= 0x0C
chan-1-forward-59-20090617112201.call-DNIS = 52301600, ANI = 201, MF = 0x20


But now I just dialed that same number and it went thru without a
problem.... 

Could be some sort of E1 state based error and not the destination number?
Maybe a "central de telmex or circuito" related?


> From: Moises Silva <moises.silva at gmail.com>
> Reply-To: <asterisk-r2 at lists.digium.com>
> Date: Wed, 17 Jun 2009 12:38:38 -0500
> To: <asterisk-r2 at lists.digium.com>
> Subject: Re: [asterisk-r2] Protocol error
> 
> On Wed, Jun 17, 2009 at 12:13 PM, Anton Krall<akrall at intruder.com.mx> wrote:
>
> Done.. Telmex will be going tomorrow to check it out.. What should I tell>
> them? To check the e1 variant on the DTU? Can a DTU be configured on a
>
> specific variant or specific number of DNIS to watch for? Or is this a
>
> problem on their side (the central box)?
You should write down the numbers
> that failed.

In the first error you posted (don't remember the number) tell
> them
that while in Group A signals you are getting signal 5, which
according
> to Telmex specification is a "reserved" signal, which
basically means the
> signal is invalid (not used). They should be
sending either signal 3 or 6 (3
> is for change to Group B signals and 6
for change to Group C signals).

In the
> second call, they request DNIS and we give them ALL the DNIS
digits we have,
> they then request more DNIS than we have. The expected
behaviour is that we
> ignore they request then they should timeout and
proceed to other request, but
> in fact, they should know (because of
the dial patterns) that no more digits
> are required to proceed.

I am not sure the Telmex specification I have can be
> considered as
"public", it was quite hard to find someone in Telmex that knew
> what I
was talking about and get the specificatoin from them, in the
> end
Martín Lara Barron from Telmex gave me the spec, I'd need to confirm
with
> him if I am allowed to post a link to it.

I suggest you make some tests
> tonight when the server is not in use
(using originate CLI command) to call
> these 2 numbers you saw failed
and see if they fail constantly. If they fail
> then you can ask them
straight forward why the calls fail to these
> numbers.

-- 
Moises Silva
Software Developer
Sangoma Technologies Inc. | 50
> McIntosh Drive, Suite 120, Markham ON
L3R 9T3 Canada
t. 1 905 474 1990 x 128 |
> e. 
> moy at sangoma.com



________________________________________________________________
Anton Krall
Direccion General

Intruder Consulting
A Division of IntruderEnterprises S.A. de C.V.
www.Intruder.com.mx
www.IntruderStore.com.mx
 
Tel. 3872-2200 ext. 201
Tel. 01-800-INTRUDER (01-800-468-7833)
Email: akrall at intruder.com.mx

Disclaimer - Junio 17, 2009 
This email and any files transmitted with it are confidential and intended solely for asterisk-r2 at lists.digium.com. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Intruder Consulting. Warning: Although Intruder Consulting has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. _______________________________________________
--Bandwidth
> and Colocation Provided by http://www.api-digital.com--

asterisk-r2 mailing
> list
To UNSUBSCRIBE or update options visit:

> http://lists.digium.com/mailman/listinfo/asterisk-r2