[asterisk-r2] OpenR2 Thailand problem

Peter Lindquist peter.lindquist.th at gmail.com
Tue Oct 28 11:14:07 CDT 2008


Dear Moises,

OK, agree with you concerning the revisions so libmfcr2 is now updated 
to latest,
unless there has been more revisions in the past 8 hours.

Concerning updating asterisk I find that doing a 'svn update' now only 
gives me
the option to use dhadi which won't compile. I'll give everyone the 
errors, but it
is basically so that we have the earlier version which compiled fine and 
having
chan_zap as a choice. What do I do to use the latest version with zap?

If I now can not use latest trixbox (where Kerry said that it was only 
to add libmfcr2
and add the configs and it would work - that is simply not true in my 
experience)
and have to recompile everything from source it is fine - but could that 
just be said
in that case? And which versions will/should/could work?

Melcon explained things well. As I said TOT are not very forthcoming 
with information
and my partner Des who suggested using ITU variant was right in so far 
that it gave
the idle pattern of 1001. The CN config was taken from the fact that 
that was was
what was said in the unicall docs and that most places you can find any 
(albeit sparse
docs) it is said that Thailand is set up same as China. This may not be 
true for this
link we have here now so that is why I am asking for help.

Now with that said there are obviously things that are wrong. The wrong 
things may
not necessarily be with openr2, but simply the fact that currently 
openr2 is not supporting
the Thai version, this is why I talked to Moises privately and I thought 
the aim was to
make openr2 supporting Thailand too. ITU is the base so we have gotten 
somewhere,
which is to say what we have is closer to ITU than to the China variant.

What to do now? I am not an R2 expert, I can't even say I have much 
experience at
all with it. I have earlier always been able to get a straight E1 PRI 
here in Bangkok,
but it seems that it is so that outside of Bangkok some Thai version of 
R2 is used.

I will ask Des to talk to TOT and ask why they are not reacting to the 
seize signal
(Des please do) and hear their reply.

Best regards,

Peter

Moises Silva wrote:
> Melcon has explained the problem quite well, the telco does not seem
> to react to our seize signal, but that could be because they don't
> recognize the seize pattern (0011). In China bits CD are always set to
> 11, that's why the IDLE signal we send is 1011. However, the telco
> sends the more common pattern 1001 (CD bits 01), which suggest the
> telco is not using the China variant.
>
> I see you already tried with the ITU variant. The next step is to also
> try upgrading your Asterisk and OpenR2 revision, you are about 10
> revisions behind, and is hard to help that way.
>
> After that you need to contact the telco and ask them why they are not
> reacting to your seize signal.
>
> On Tue, Oct 28, 2008 at 4:35 AM, Melcon Moraes <melcon at gmail.com> wrote:
>   
>> For some reason, Telco is not seeing your changing bits(SEIZE), as you
>> can see on the logs:
>>
>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - ABCD Tx >> [SEIZE] 0x00
>>
>> then 8 seconds after:
>>
>> [Oct 27 21:06:40] WARNING[13425] chan_zap.c: Chan 1 - Seize Timeout Expired!
>>
>> Don't worry about the "ignoring" when reloading zap channel. Since the
>> channel got its configuration at the first start, it will ignore
>> future value changes until you restart asterisk.
>>
>> Do you have any reason for mfcr2_get_ani_first=no ?
>>
>> How's your zaptel.conf?
>>
>> BTW, your TX bits using CN as a mfcr2 variant was sending 1011, not
>> 1101 as stated before and 1011 is IDLE as well.
>>
>> []'s
>> MM
>>
>> On Tue, Oct 28, 2008 at 7:03 AM, Peter Lindquist
>> <peter.lindquist.th at gmail.com> wrote:
>>     
>>> Des,
>>>
>>> Tested with that and that is now showing 1001/1001 for channel 1.
>>>
>>> The results from calling in/out are the same.
>>>
>>> //Peter
>>>
>>> Des Hawes wrote:
>>>       
>>>> Maybe should change the mfcr2 variant from CN to the ITU variant
>>>>
>>>> Des Hawes
>>>> Director - MetaVox Ltd.
>>>> 15th Floor 253 Sukhumvit Soi 21 (Asoke),
>>>> Klongtoey Nua, Wattana Bangkok 10110
>>>> p:026641290  f:026641296  m: 0816222210
>>>>
>>>> -----Original Message-----
>>>> From: asterisk-r2-bounces at lists.digium.com
>>>> [mailto:asterisk-r2-bounces at lists.digium.com] On Behalf Of Peter Lindquist
>>>> Sent: Tuesday, October 28, 2008 2:59 PM
>>>> To: asterisk-r2 at lists.digium.com
>>>> Subject: Re: [asterisk-r2] OpenR2 Thailand problem
>>>>
>>>> Juan Carlos, sorry yes, forgot to say. The telco only provides 1 channel
>>>> for now to test.
>>>>
>>>> The zttool was run while asterisk was running. Just double checked.
>>>>
>>>> How do I make asterisk send 1001 instead of 1101?
>>>>
>>>> //Peter
>>>>
>>>> Juan Carlos Huerta wrote:
>>>>
>>>>         
>>>>> Peter, how many channels does your Telco provides you in the E1 link?
>>>>> zttool only see the first channel unblocked (1001) from the Telco side
>>>>> (Rx). Did you copy the zttool screen while Asterisk and chan_zap.so
>>>>> still up and running? 'cause in the Asterisk side (Tx) it should be
>>>>> 1001 to be IDLE instead of 1101.
>>>>>
>>>>> Try to get the same report and be sure that Asterisk is up and send it
>>>>>
>>>>>           
>>>> again.
>>>>
>>>>         
>>>>> Juan Carlos
>>>>>
>>>>> On Mon, Oct 27, 2008 at 11:38 PM, Peter Lindquist
>>>>> <peter.lindquist.th at gmail.com> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Dear all,
>>>>>>
>>>>>> Trying to get OpenR2 working in Thailand with TOT (Telephone
>>>>>> Organization of Thailand). Unfortunately I have very little information
>>>>>> from TOT, they basically just say it's a E1 CAS R2 they provide.
>>>>>>
>>>>>> I have latest Trixbox set up together with libmfcr2 (OpenR2 version:
>>>>>> 0.1.1, revision: 64) and asterisk compiled from the svn source
>>>>>> (1.4.21.2) from libopenr2.org.
>>>>>>
>>>>>> My problems are the following:
>>>>>>
>>>>>> 1) When I make an incoming call - there is absolutely nothing happening,
>>>>>> I see no ring indication or anything on the PBX. The call is eventually
>>>>>> timed out by my telco.
>>>>>>
>>>>>> 2) When I make an outgoing call I see the following in the asterisk log:
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: no MFC/R2 category specified
>>>>>> for chan Zap/1-1, using default National Subscriber
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - Attempting to make
>>>>>> call (ANI=2133, DNIS=0819369108, category=National Subscriber)
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - ABCD Raw Rx << 0x09
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - No change in bits
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - Call started at Mon
>>>>>> Oct 27 21:06:32 2008 on chan 1
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - ABCD Tx >> [SEIZE]
>>>>>>
>>>>>>             
>>>> 0x00
>>>>
>>>>         
>>>>>> [Oct 27 21:06:32] DEBUG[13425] chan_zap.c: Chan 1 - ABCD Raw Tx >> 0x03
>>>>>> [Oct 27 21:06:32] VERBOSE[13425] logger.c:     -- Called g0/0819369108
>>>>>> [Oct 27 21:06:40] DEBUG[13425] chan_zap.c: Chan 1 - calling callback on
>>>>>> chan 1
>>>>>> [Oct 27 21:06:40] WARNING[13425] chan_zap.c: Chan 1 - Seize Timeout
>>>>>>
>>>>>>             
>>>> Expired!
>>>>
>>>>         
>>>>>> [Oct 27 21:06:40] ERROR[13425] chan_zap.c: Chan 1 - Protocol error.
>>>>>> Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF
>>>>>> Engine Off, MF Group$
>>>>>> [Oct 27 21:06:40] DEBUG[13425] chan_zap.c: Chan 1 - DNIS = 0819369108,
>>>>>> ANI = 2133, Last MF Signal =
>>>>>> [Oct 27 21:06:40] DEBUG[13425] chan_zap.c: Chan 1 - ABCD Tx >> [IDLE]
>>>>>>
>>>>>>             
>>>> 0x08
>>>>
>>>>         
>>>>>> [Oct 27 21:06:40] DEBUG[13425] chan_zap.c: Chan 1 - ABCD Raw Tx >> 0x0B
>>>>>> [Oct 27 21:06:40] ERROR[13425] chan_zap.c: MFC/R2 protocol error on chan
>>>>>> 1: Seize Timeout
>>>>>> [Oct 27 21:06:40] DEBUG[13425] chan_zap.c: disconnecting MFC/R2 call on
>>>>>> chan 1
>>>>>>
>>>>>>
>>>>>> 3) When reloading chan_zap I see:
>>>>>> [Oct 27 21:10:09] VERBOSE[13434] logger.c:     -- Reloading module
>>>>>> 'chan_zap.so' (Zapata Telephony)
>>>>>> [Oct 27 21:10:09] VERBOSE[13434] logger.c:   == Parsing
>>>>>> '/etc/asterisk/zapata.conf': [Oct 27 21:10:09] VERBOSE[13434] logger.c:
>>>>>> Found
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring signalling
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_variant
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_get_ani_first
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_max_ani
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_max_dnis
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_category
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_logdir
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_logging
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring mfcr2_call_files
>>>>>> [Oct 27 21:10:09] WARNING[13434] chan_zap.c: Ignoring
>>>>>> mfcr2_metering_pulse_timeout
>>>>>> [Oct 27 21:10:09] VERBOSE[13434] logger.c:     -- Reconfigured channel
>>>>>> 1, MFC/R2 signalling
>>>>>> ..
>>>>>> [Oct 27 21:10:09] VERBOSE[13434] logger.c:     -- Reconfigured channel
>>>>>> 31, MFC/R2 signalling
>>>>>>
>>>>>> Even if my /etc/asterisk/zapata.conf has:
>>>>>> ;MFCR2 settings
>>>>>> signalling=mfcr2
>>>>>> mfcr2_variant=cn
>>>>>> mfcr2_get_ani_first=no
>>>>>> mfcr2_max_ani=20
>>>>>> mfcr2_max_dnis=7
>>>>>> mfcr2_category=national_subscriber
>>>>>> mfcr2_logdir=span1
>>>>>> mfcr2_logging=all
>>>>>> mfcr2_call_files=yes
>>>>>> mfcr2_metering_pulse_timeout=-1
>>>>>> callgroup=0
>>>>>> pickupgroup=0
>>>>>> channel => 1-15,17-31
>>>>>>
>>>>>> 4) Some other info:
>>>>>> core show channeltypes:
>>>>>> Zap         Zapata Telephony Driver w/PRI w/OPENR2   no
>>>>>> yes          no
>>>>>>
>>>>>> mfcr2 show channels:
>>>>>> Chan Variant Max ANI Max DNIS ANI First Immediate Accept Tx State Rx
>>>>>>
>>>>>>             
>>>> State
>>>>
>>>>         
>>>>>>   1 CN      20      7        No        No               IDLE     IDLE
>>>>>>   2 CN      20      7        No        No               IDLE     BLOCK
>>>>>> ..
>>>>>>  31 CN      20      7        No        No               IDLE     BLOCK
>>>>>>
>>>>>> zttool:
>>>>>> Current Alarms:     No alarms.
>>>>>> Sync Source:        Rhino R1T1 E1/PRA Card 0
>>>>>> IRQ Misses:               0
>>>>>> Bipolar Viol:             0
>>>>>> Tx/Rx Levels:         0/  0
>>>>>> Total/Conf/Act:      31/ 31/ 30
>>>>>>                 1111111111222222222233
>>>>>>        1234567890123456789012345678901
>>>>>>    TxA 111111111111111-111111111111111
>>>>>>    TxB 000000000000000-000000000000000
>>>>>>    TxC 111111111111111-111111111111111
>>>>>>    TxD 111111111111111-111111111111111
>>>>>>
>>>>>>    RxA 111111111111111-111111111111111
>>>>>>    RxB 011111111111111-111111111111111
>>>>>>    RxC 011111111111111-111111111111111
>>>>>>    RxD 111111111111111-111111111111111
>>>>>>
>>>>>> I could really use some help in how to troubleshoot this and get it
>>>>>>
>>>>>>             
>>>> working!
>>>>
>>>>         
>>>>>> Best regards,
>>>>>>
>>>>>> Peter Lindqvist
>>>>>> www.voxion.net / www.voipperiod.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> --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
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> --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
>>>>
>>>>
>>>> _______________________________________________
>>>> --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
>>>>
>>>>
>>>>         
>>> _______________________________________________
>>> --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
>>>
>>>       
>> _______________________________________________
>> --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
>>
>>     
>
>
>
>   



More information about the asterisk-r2 mailing list