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 <[email protected]> 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 >> <[email protected]> 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 > -- "I do not agree with what you have to say, but I’ll defend to the death your right to say it." Voltaire _______________________________________________ -- 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
