[asterisk-r2] Asterisk OpenR2 CAS and Private Wires Manual Ringdown and AutoRingdown (MRD and ARD)

Mc GRATH Ricardo mcgrathr at mail2web.com
Mon Sep 16 09:00:10 CDT 2013


Hi Kayode Olajide 

First of all, you should check at both side it will use the same  technology system, as a E1CAS HDB3, or E1 CCS HDB3 these last one, as used same frame system it distinguish if E1 MFC-R2 or ISDN PRI system, because are based on 2 MB physical layer  with 32 channels (alignment, signalling and voice 30 ch).
In order to  use MFC-R2 Line Signalling configuration both side should used the same Line Signalling, same point for MFC-R2 Register Signalling.
E1 MFC-R2 is a compelled based on CCITT recommendations as  Q.421 and Q.422, Channel Associated Signalling (CAS) framing is based on 4 signalling bits, but mainly use only 2 of them per direction.
These last mean CAS basically there isn't variant to state of IDLE, Seize, Seize Ack, etc. ,the only differences becomes onto tones that request or transmit specific information in the protocol, forward and backward destination and designation signals.
I hope help with shortest MFC-R2 explanation, it still one of the oldest technology used on Data switching technology.
Best regards, good luck

Mc GRATH Ricardo
E-Mail mcgrathr at mail2web.com
________________________________________
From: asterisk-r2-bounces at lists.digium.com [asterisk-r2-bounces at lists.digium.com] On Behalf Of Kayode Olajide [kayode at gltd.net]
Sent: 16 September 2013 07:33
To: asterisk-r2 at lists.digium.com
Subject: [asterisk-r2] Asterisk OpenR2 CAS and Private Wires Manual Ringdown and AutoRingdown (MRD and ARD)

Hi,

I was wondering if anyone has successfully setup the above type of configuration. I setup an Asterisk 1.6.2.24 with Digium T100P card. My understanding is CAS configurations for private wires is slightly different to PBXs as there is no onhook or offhook state. With Private wires, the signalling is kind of cut off, and audio is passed straight from one end to the other. I was wondering if this is currently possible to set up in the openr2 configuration.

Currently I have an Asterisk system connected to one of such providers. They are called Etrali (formerly part of Orange Business Systems) there are a few others like BT, SpeakerBus, IPC etc.

My config files is as follows:

/etc/dahdi/system.conf

span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
loadzone=us
defaultzone=us


/etc/asterisk/chan_dahdi.conf

[channels]
context=from-pstn1
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes

signalling=mfcr2
mfcr2_variant=cn
mfcr2_get_ani_first=no
mfcr2_max_ani=15
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_call_files=yes
mfcr2_dtmf_dialing=yes
mfcr2_dtmf_detection=no
mfcr2_mfback_timeout=1500
mfcr2_metering_pulse_timeout=1500
mfcr2_logdir=etrali
mfcr2_logging=all
;mfcr2_advanced_protocol_file=/etc/r2proto.conf

group=1
callgroup=1
pickupgroup=1
channel => 1-15,17-31


When I run the command below:

 mfcr2 show channels
Chan Variant Max ANI Max DNIS ANI First Immediate Accept Tx CAS   Rx CAS
   1 CN      15      4        No        No               IDLE     BLOCK
   2 CN      15      4        No        No               IDLE     BLOCK
   3 CN      15      4        No        No               IDLE     BLOCK
   4 CN      15      4        No        No               IDLE     BLOCK
   5 CN      15      4        No        No               IDLE     BLOCK
   6 CN      15      4        No        No               IDLE     BLOCK
   7 CN      15      4        No        No               IDLE     BLOCK
   8 CN      15      4        No        No               IDLE     BLOCK
   9 CN      15      4        No        No               IDLE     BLOCK
  10 CN      15      4        No        No               IDLE     BLOCK
  11 CN      15      4        No        No               IDLE     BLOCK
  12 CN      15      4        No        No               IDLE     BLOCK
  13 CN      15      4        No        No               IDLE     BLOCK
  14 CN      15      4        No        No               IDLE     BLOCK
  15 CN      15      4        No        No               IDLE     BLOCK
  17 CN      15      4        No        No               IDLE     BLOCK
  18 CN      15      4        No        No               IDLE     BLOCK
  19 CN      15      4        No        No               IDLE     BLOCK
  20 CN      15      4        No        No               IDLE     BLOCK
  21 CN      15      4        No        No               IDLE     BLOCK
  22 CN      15      4        No        No               IDLE     BLOCK
  23 CN      15      4        No        No               IDLE     BLOCK
  24 CN      15      4        No        No               IDLE     BLOCK
  25 CN      15      4        No        No               IDLE     BLOCK
  26 CN      15      4        No        No               IDLE     BLOCK
  27 CN      15      4        No        No               IDLE     BLOCK
  28 CN      15      4        No        No               IDLE     BLOCK
  29 CN      15      4        No        No               IDLE     BLOCK
  30 CN      15      4        No        No               IDLE     BLOCK
  31 CN      15      4        No        No               IDLE     BLOCK

When an incoming call comes in on Channel 1, the message is shown below:


[Sep 12 14:46:19] DEBUG[19310]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - Bits changed from 0x0C to 0x04
[Sep 12 14:46:19] DEBUG[19310]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - CAS Rx << [0x04] 0x04
[Sep 12 14:46:19] ERROR[19310]: chan_dahdi.c:2004 dahdi_r2_write_log: Chan 1 - Protocol error. Reason = Invalid CAS, R2 State = Idle, MF state = MF Engine Off, MF Group = No Group, CAS = 0x04
DNIS = , ANI = , MF = 0x20
[Sep 12 14:46:19] DEBUG[19310]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - CAS Tx >> [IDLE] 0x08
[Sep 12 14:46:19] DEBUG[19310]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - CAS Raw Tx >> 0x0B
[Sep 12 14:46:19] ERROR[19310]: chan_dahdi.c:1789 dahdi_r2_on_protocol_error: MFC/R2 protocol error on chan 1: Invalid CAS
[Sep 12 14:46:20] DEBUG[19310]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - Bits changed from 0x04 to 0x0C
[Sep 12 14:46:20] DEBUG[19310]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - CAS Rx << [BLOCK] 0x0C
[Sep 12 14:46:20] NOTICE[19310]: chan_dahdi.c:2026 dahdi_r2_on_line_blocked: Far end blocked on chan 1

I have also attached the call files generated from the logs.

Would appreciate any help in getting this working.

Thanks


Kayode Olajide

Globility Ltd.
40-42 Cannon Street,
London,
EC4N 6JJ

Tel: +44(0)20 7100 1499

Mob: +44(0)75 1724 7059

Internet communications are not secure and therefore Globility Limited
does not accept legal responsibility for the contents of this message.
Any views or opinions presented do not necessarily represent those of
Globility Limited unless otherwise stated.


More information about the asterisk-r2 mailing list