[asterisk-users] Multi Frequency Cycle Timeout - E1-R2 METROTEL COLOMBIA

Giovanny Magallanes gmagallanes at gmail.com
Fri Apr 10 22:42:30 CDT 2009


Hi Moises and Steve,

I tried with all protocol variants for Openr2 (AR, BR, CN, CZ, CO, EC, ITU,
MX, PH, VE) and setting "mfcr2_skip_category=yes", but the problem persists.
I tried with Unicall and, in this way, I could make and receive calls
without problems, using protocol variant BR or CO (I did not try with
another variants).
Moises, if you wish the next Monday (4/13) we can chat (off-list) for this
issue.

Thanks for your attention.

Giovanny Magallanes

2009/4/8 Giovanny Magallanes <gmagallanes at gmail.com>

> Hi Moises,

> The Natural Microsystems document describes the two Colombian variants
> supported by Unicall. They are both a bit like China. The key difference
> between them in detecting the end of variable length digit strings.. The
> cellular one requires a timeout and pulsing of A3 to detect the end of
> variable length digit strings. This is an awful technique, as it really
> slows things down. However, several places do it. What I think happens,
> and what is not clearly described in the Natural Microsystems document,
> is that if a calling party category is not available you might need to
> do a timeout and pulse A3 for that, as well as for digit strings.

> I have some notes on a third Colombian protocol, which I haven't
> implemented in Unicall, as I don't have complete information. My notes
> say the category and the ANI are both requested using A-6, and the ANI
> must be requested after the DNIS is complete. Those notes don't indicate
> what all the other signals are - i.e. DNIS request, number complete, etc.

> Steve


> Moises Silva wrote:
>>* The OpenR2 CO variant was implemented using the specification found in*
>>* a CAS protocols reference manual by Natural MicroSystems. It was*
>>* tested by someone in Colombia but I don't remember the telco though.*
>>
>>* Unicall uses the same A-6 signal to request calling party category,*
>>* which is the one openr2 is using too. It seems the telco does not like*
>>* this signal and is just ignoring it and openr2 eventually times out*
>>* waiting for the category.*
>>
>>*  Giovanny, if the problem persist after my recommendation contact me*
>>* off-list to arrange a debug session.*
>>
>>* Moy*
>>
>>* On Thu, Apr 9, 2009 at 8:02 AM, Steve Underwood <steveu at xxxxxxxxxxx> wrote:*
>>*   *
>>*> Hi,*
>>*>*
>>*> There are at least 2 R2 protocol variants in Colombia - one used by land*
>>*> lines, and one used by the cellular networks. Unicall implements both,*
>>*> and I think both have been used successfully by people in Colombia (I*
>>*> seem to remember debugging with people there long ago). Which is the*
>>*> protocol called "CO" in openr2?*
>>*>*
>>*> Steve.*
>>*>*
>>*> Moises Silva wrote:*
>>*>     *
>>*>> Sounds like a protocol variant issue. Is the telco supposed to send you ANI?*
>>*>>*
>>*>> You have 2 options, the first option is to try with the ITU variant,*
>>*>> if that does not work, set the option mfcr2_skip_category=yes and see*
>>*>> if that helps.*
>>*>>*
>>*>> Moy*
>>*>>*
>>*>> On Wed, Apr 8, 2009 at 6:06 PM, Giovanny Magallanes*
>>*>> <gmagallanes at xxxxxxxxx> wrote:*
>>*>>*
>>*>>       *
>>*>>> Hi,*
>>*>>>*
>>*>>> I have installed Elastix 1.5.2 (Barranquilla, Colombia (TELCO: METROTEL))*
>>*>>> with a TE220P (2xE1) and TDM2400P (16FXS), openr2 is included in 1.5.2*
>>*>>> version. The outcoming calls are ok, but with incoming call i have an error:*
>>*>>>*
>>*>>> ERROR[14972] chan_dahdi.c: Chan 2 - Protocol error. Reason = Multi Frequency*
>>*>>> Cycle Timeout, R2 State =*
>>*>>> Seize ACK Transmitted, MF state = Category Request Transmitted, MF Group =*
>>*>>> Backward Group A, CAS = 0x00*
>>*>>> DNIS = 310, ANI = , MF = 0x20*
>>*>>>*
>>*>>> I tried with all protocol variants availables, because seems thats the*
>>*>>> cause, but I still have the problem.*
>>*>>>*
>>*>>> elastix*CLI> mfcr2 show variant*
>>*>>> Variant Code                                  Country*
>>*>>>   AR                                Argentina*
>>*>>>   BR                                   Brazil*
>>*>>>   CN                                    China*
>>*>>>   CZ                           Czech Republic*
>>*>>>   CO                                 Colombia*
>>*>>>   EC                                  Ecuador*
>>*>>>  ITU    International Telecommunication Union*
>>*>>>   MX                                   Mexico*
>>*>>>   PH                              Philippines*
>>*>>>   VE                                Venezuela*
>>*>>> elastix*CLI>*
>>*>>>*
>>*>>>*
>>*>>>*
>>*>>> The following link has the content of files: chan_dahdi.conf, system.conf,*
>>*>>> and a tail of /var/log/asterisk/full*
>>*>>>*
>>*>>> http://pastebin.com/f3424b319*
>>*>>>*
>>*>>> Is this really a variant protocol problem? Any suggest?*
>>*>>>*
>>*>>> Regards,*
>>*>>>*
>>*>>>*
>>*>>>*
>>*>>> GM*
>>*>>>*
>>*>>> _______________________________________________*
>>*>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --*
>>*>>>*
>>*>>> 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 --*
>>*>*
>>*> 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/20090410/29b0878a/attachment.htm 


More information about the asterisk-users mailing list