<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Moy,<br>
<br>
Today I talked again with NEC and all they were able to say was that we
should use CAS signaling states only but not R2 register signaling or
address signaling, meaning that we should get the call as soon as the
CAS protocol has accepted the call. He was not able to give more
technical details. According to him this is a straight forward CAS
connection with no other protocol involved. <br>
I hope this makes sense to you.<br>
<br>
Moises Silva escribió:
<blockquote
cite="mid:c4d05cbe0810210754k13f02395j22935a88828665c7@mail.gmail.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:ignacio.rodriguez@supportcenter.cl"><ignacio.rodriguez@supportcenter.cl></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:ignacio.rodriguez@supportcenter.cl"><ignacio.rodriguez@supportcenter.cl></a> 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 <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-r2 mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-r2">http://lists.digium.com/mailman/listinfo/asterisk-r2</a>
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-r2 mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-r2">http://lists.digium.com/mailman/listinfo/asterisk-r2</a>
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-r2 mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-r2">http://lists.digium.com/mailman/listinfo/asterisk-r2</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>