[asterisk-r2] Asterisk with R2 not forwarding calls

Tue Oct 21 09:54:28 CDT 2008

I'd not know what they mean by "the basic bit protocol". However, this
whatever they are asking for, is not supported. OpenR2 is, hum, well,
for MFC/R2 and eventually DTMF/R2. If you can ask more technical
details that may help to see if I can implement it (if it makes any
sense to implement it in OpenR2).

Moisés Silva

On Tue, Oct 21, 2008 at 8:10 AM, Ignacio Rodriguez
<ignacio.rodriguez at supportcenter.cl> wrote:
> Moy,
>
> I was able to talk to NEC people and they told me that the iterface is
> configure as a pure E1 CAS, without the R2 protocol.
> He is telling me that I need to do the same, not to implement R2 and use the
> basic bit protocol.
> Is this possible with this library?
>
> Thanks,
>
> Ignacio
>
> Moises Silva escribió:
>
> Ignacio,
>
> The SMDI protocol has nothing to do with R2. You can safely ignore that
> message.
>
> I still see pretty much the same, after Asterisk receives the Seize,
> sends the Seize ACK, at that point the NEC should send us the first
> DNIS digit, but we don't receive anything, and I even suspect the NEC
> is not even receiving our Seize ACK.
>
> You need someone to check the NEC side to determine why is not seeing
> Asterisk CAS signals.
>
> Moy
>
>
>
> I did some more research and I found the following:
>
> This is a call received from the NEC pbx (placing a call from a NEC
> extension)
>
> debian*CLI>
> [Oct 16 18:14:22] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Raw Rx << 0x01
> [Oct 16 18:14:22] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - Bits changed from 0x08 to 0x00
> [Oct 16 18:14:22] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Rx << [SEIZE] 0x00
> [Oct 16 18:14:22] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Tx >> [SEIZE ACK] 0x0C
> [Oct 16 18:14:22] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Raw Tx >> 0x0D
> [Oct 16 18:14:22] NOTICE[2624]: chan_dahdi.c:1331 dahdi_r2_on_call_init: New
> MFC/R2 call detected on chan 2.
> debian*CLI>
> debian*CLI>
>
>
> Then after hanging up I received the following:
>
>
> [Oct 16 18:20:30] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Raw Rx << 0x09
> [Oct 16 18:20:30] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - Bits changed from 0x00 to 0x08
> [Oct 16 18:20:30] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Rx << [CLEAR FORWARD] 0x08
> [Oct 16 18:20:30] NOTICE[2624]: chan_dahdi.c:1534 dahdi_r2_write_log: Chan 2
> - Far end disconnected. Reason: Normal Clearing
> [Oct 16 18:20:30] NOTICE[2624]: chan_dahdi.c:1491
> dahdi_r2_on_call_disconnected: MFC/R2 call disconnected on chan 2
> [Oct 16 18:20:30] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - Call ended
> [Oct 16 18:20:30] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Tx >> [IDLE] 0x08
> [Oct 16 18:20:30] DEBUG[2624]: chan_dahdi.c:1546 dahdi_r2_write_log: Chan 2
> - ABCD Raw Tx >> 0x09
> [Oct 16 18:20:30] NOTICE[2624]: chan_dahdi.c:1403 dahdi_r2_on_call_end:
> MFC/R2 call end on chan 2
> debian*CLI>
>
> Then I checked the messages file and found I am getting the following
> message right after the call is detected.
>
> [Oct 16 19:46:42] NOTICE[2703] res_smdi.c: No SMDI interfaces are available
> to listen on, not starting SMDI listener.
>
> I wonder if the problem is right there, where Asterisk is not transferring
> calls to the dialplan.
>
> Thanks,
>
> Ignacio
>
>
>
> Moises Silva escribió:
>
> Hola Ignacio,
>
> For the incoming call, this is what is happening:
>
> Asterisk correctly detect that a new call is arriving, then it
> acknowledges the "start a call" message. But 4 seconds after that, we
> receive a "Clear Forward" message which basically means the calling
> end is requesting hangup. It is very likely that somehow the Nec PBX
> is not seeing the bit change we did.
>
> For the outgoing call:
>
> Asterisk "requests a call" and the other end does not respond in the
> 7/8 seconds that we wait for them, therefore we just hangup, again,
> this looks like the Nec PBX does not recognize our bit pattern change
> and therefore does not detect our call attempt.
>
> Is there any chance you can get a trace of the NEC Pbx? How do you
> have connected the NEC to Asterisk?
>
> Moy
>
> On Thu, Sep 25, 2008 at 9:18 AM, Ignacio Rodriguez
> <ignacio.rodriguez at supportcenter.cl> wrote:
>
>
> Hi everyone,
>
>
>
> I was ignorant about R2 until I got a someone reuesting to connect a Nec PBX
> to an Asterisk box using the E1 R2 interface (no pri available).
> After several trial and error attempts I was able to build Asterisk 1.6 with
> Moises's Openr2 library (I had to realize several other things like the fact
> that 1.6 only works with Dahdi).  Unfortunately I am still having problems
> and I hope you can help me.
>
> For some reason when I make calls from the NEC PBX to Asterisk and vice
> versa the calls are not going thru. For incoming calls I see the following
> messages in CLI:
>
> [Sep 23 19:11:22] NOTICE[2609]: chan_dahdi.c:1331 dahdi_r2_on_call_init: New
> MFC/R2 call detected on chan 3.
> [Sep 23 19:11:57] NOTICE[2609]: chan_dahdi.c:1534 dahdi_r2_write_log: Chan 3
> - Far end disconnected. Reason: Normal Clearing
> [Sep 23 19:11:57] NOTICE[2609]: chan_dahdi.c:1491
> dahdi_r2_on_call_disconnected: MFC/R2 call disconnected on chan 3
> [Sep 23 19:11:57] NOTICE[2609]: chan_dahdi.c:1403 dahdi_r2_on_call_end:
> MFC/R2 call end on chan 3
>
>
>
> The first one corresponds to the moment when the call starts and the other 3
> when hung up.
>
> I have using all the debugging tools available from Dahdi (dahdi_test,
> sahdi_tool and dahdi_monitor) and all them show some kind of activity (
> changing ABCD bits) which makes me believe the problem is not with dahdi but
> with Asterisk not forwarding the calls (just a supposition).
>
> My chan_dahdi.conf is
>
> [trunkgroups]
>
> [channels]
> 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=itu
> mfcr2_get_ani_first=no
> mfcr2_max_ani=20
> mfcr2_max_dnis=4
> mfcr2_category=national_subscriber
> mfcr2_logdir=span1
> mfcr2_logging=all
>
> context=nec
> group=0
> callgroup=0
> pickupgroup=0
> channel => 1-15
> channel => 17-31
>
> And my  /etc/dahdi/system.conf is
>
> loadzone = us
> defaultzone = us
>
> span=1,1,0,cas,hdb3
> cas=1-15:1101
> cas=17-31:1101
> dchan=16
>
> I also got some debugging lines (from /var/log/asterisk/mcfr2/span1
> directory). The first corresponding to one incoming call and the second for
> an outgoing call.
>
> Incoming
>
>
>
> 20:09:19:541] [Thread: 3077131184] [Chan 5] - Call started at Tue Sep 23
>
> 20:09:19 2008 on chan 5
>
> [20:09:19:541] [Thread: 3077131184] [Chan 5] - ABCD Tx >> [SEIZE ACK] 0x0C
>
> [20:09:19:542] [Thread: 3077131184] [Chan 5] - ABCD Raw Tx >> 0x0D
>
> [20:09:23:701] [Thread: 3077131184] [Chan 5] - ABCD Raw Rx << 0x09
>
> [20:09:23:701] [Thread: 3077131184] [Chan 5] - Bits changed from 0x00 to
>
> 0x08
>
> [20:09:23:701] [Thread: 3077131184] [Chan 5] - ABCD Rx << [CLEAR
>
> FORWARD] 0x08
>
> [20:09:23:701] [Thread: 3077131184] [Chan 5] - Far end disconnected.
>
> Reason: Normal Clearing
>
> [20:09:23:701] [Thread: 3077131184] [Chan 5] - Call ended
>
>
>
> Outgoing
>
> [20:10:50:350] [Thread: 3066108848] [Chan 31] - Call started at Tue Sep
>
> 23 20:10:50 2008 on chan 31
>
> [20:10:50:350] [Thread: 3066108848] [Chan 31] - ABCD Tx >> [SEIZE] 0x00
>
> [20:10:50:350] [Thread: 3066108848] [Chan 31] - ABCD Raw Tx >> 0x01
>
> [20:10:58:370] [Thread: 3066108848] [Chan 31] - calling callback on chan 31
>
> [20:10:58:370] [Thread: 3066108848] [Chan 31] - Seize Timeout Expired!
>
> [20:10:58:370] [Thread: 3066108848] [Chan 31] - Protocol error. Reason =
>
> Seize Timeout, R2 State = Seize Transmitted, MF state $
>
> [20:10:58:370] [Thread: 3066108848] [Chan 31] - DNIS = 150, ANI = 6000,
>
> Last MF Signal =
>
>
>
> Please let me know if someone can give me an idea of where the problem could
> be.
>
>
>
>
>
> Thanks,
>
>
>
> Ignacio
>
> _______________________________________________
> --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
>

-- 
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire