Eduardo Pimenta
2012-Apr-14 15:19 UTC
[asterisk-users] Dahdi QSIG with Tadiran Coral - not working
Hello All,
we have Asterisk 1.8 connected to Tadiran Coral via RedFone Fonebridge. Our
side is pri-net and Tadiran is pri-CPE, both sides have QSIG enabled.
We are able to call internal user extensions in Tadiram and we are able to
do outbound calls using Tadiran routes. We are even able to call outbound
and perform DahdiSendCallReroutingFacility to internal user extension in
Tadiram, thus joining both calls and freeing the channel in our Asterisk
(this is a QSIG facility), as seen below.
where 0019xxxxxxxx is my mobile fone number.
1) Call my fone number
2) send it to extension 2 at ura
3) extension 2 at ura plays a message and calls DAHDISendCallreroutingFacility
sending it to user extension 5501.
4) Fonebridge/Asterisk channel is released, "pri show channels" shows
us
that the call is not in our realm anymore.
5) Two connected legs can normally talk.
[Apr 9 12:51:47] DEBUG[18196] sig_pri.c: sig_pri_request 1
[Apr 9 12:51:47] DEBUG[18196] sig_pri.c: CALLER NAME: NUM:
[Apr 9 12:51:47] VERBOSE[18196] sig_pri.c: -- Requested transfer
capability: 0x00 - SPEECH
[Apr 9 12:51:54] VERBOSE[18199] pbx.c: -- Executing [2 at ura:1]
Playback("DAHDI/i1/0019xxxxxxxx-2", "custom/ura/seguranca")
in new stack
[Apr 9 12:51:54] VERBOSE[18199] file.c: -- <DAHDI/i1/0019xxxxxxxx-2>
Playing 'custom/ura/seguranca.slin' (language 'en')
[Apr 9 12:51:59] VERBOSE[18199] pbx.c: -- Executing [2 at ura:2]
DAHDISendCallreroutingFacility("DAHDI/i1/0019xxxxxxx-2",
"5501") in new
stack
[Apr 9 12:51:59] WARNING[18199] chan_dahdi.c: Callrerouting Facility
without original called number argument
[Apr 9 12:51:59] NOTICE[18199] chan_dahdi.c: Callrerouting Facility
without diversion reason argument, defaulting to unknown
[Apr 9 12:51:59] VERBOSE[18199] pbx.c: == Spawn extension (ura, 2, 2)
exited non-zero on 'DAHDI/i1/0019xxxxxxxx-2'
[Apr 9 12:51:59] VERBOSE[18199] chan_dahdi.c: -- Hungup
'DAHDI/i1/0019xxxxxxxx-2'
But, inbound to our system, Tadiran can send us absolutely nothing. I have
set "pri intense debug span 1" and cannot see anything happening
coming
from Tadiram. No log at all, only exchange of regular protocol messages.
My conclusion is that Tadiram tech guys are doing something wrong when
trying to send us a call. Is it possible that, even having no log messages,
no error messages, and after beeing able to do the mentioned above, that
the problem is in our side?
Thanks,
Eduardo
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20120414/3dfb1018/attachment.htm>
Hi Eduardo, we use redfone in most of our projects. If you have enabled intense debug on that particular span, you should see some logs coming in from your Tadiran. If you don't see any, the problem is from Tadiran side, I highly suspect. On Sat, Apr 14, 2012 at 11:19 PM, Eduardo Pimenta <edu at alertbrasil.com.br>wrote:> Hello All, > > we have Asterisk 1.8 connected to Tadiran Coral via RedFone > Fonebridge. Our side is pri-net and Tadiran is pri-CPE, both sides have > QSIG enabled. > > We are able to call internal user extensions in Tadiram and we are able to > do outbound calls using Tadiran routes. We are even able to call outbound > and perform DahdiSendCallReroutingFacility to internal user extension in > Tadiram, thus joining both calls and freeing the channel in our Asterisk > (this is a QSIG facility), as seen below. > > where 0019xxxxxxxx is my mobile fone number. > > 1) Call my fone number > 2) send it to extension 2 at ura > 3) extension 2 at ura plays a message and calls > DAHDISendCallreroutingFacility sending it to user extension 5501. > 4) Fonebridge/Asterisk channel is released, "pri show channels" shows us > that the call is not in our realm anymore. > 5) Two connected legs can normally talk. > > > [Apr 9 12:51:47] DEBUG[18196] sig_pri.c: sig_pri_request 1 > [Apr 9 12:51:47] DEBUG[18196] sig_pri.c: CALLER NAME: NUM: > [Apr 9 12:51:47] VERBOSE[18196] sig_pri.c: -- Requested transfer > capability: 0x00 - SPEECH > [Apr 9 12:51:54] VERBOSE[18199] pbx.c: -- Executing [2 at ura:1] > Playback("DAHDI/i1/0019xxxxxxxx-2", "custom/ura/seguranca") in new stack > [Apr 9 12:51:54] VERBOSE[18199] file.c: -- <DAHDI/i1/0019xxxxxxxx-2> > Playing 'custom/ura/seguranca.slin' (language 'en') > [Apr 9 12:51:59] VERBOSE[18199] pbx.c: -- Executing [2 at ura:2] > DAHDISendCallreroutingFacility("DAHDI/i1/0019xxxxxxx-2", "5501") in new > stack > [Apr 9 12:51:59] WARNING[18199] chan_dahdi.c: Callrerouting Facility > without original called number argument > [Apr 9 12:51:59] NOTICE[18199] chan_dahdi.c: Callrerouting Facility > without diversion reason argument, defaulting to unknown > [Apr 9 12:51:59] VERBOSE[18199] pbx.c: == Spawn extension (ura, 2, 2) > exited non-zero on 'DAHDI/i1/0019xxxxxxxx-2' > [Apr 9 12:51:59] VERBOSE[18199] chan_dahdi.c: -- Hungup > 'DAHDI/i1/0019xxxxxxxx-2' > > > But, inbound to our system, Tadiran can send us absolutely nothing. I have > set "pri intense debug span 1" and cannot see anything happening coming > from Tadiram. No log at all, only exchange of regular protocol messages. > > > My conclusion is that Tadiram tech guys are doing something wrong when > trying to send us a call. Is it possible that, even having no log messages, > no error messages, and after beeing able to do the mentioned above, that > the problem is in our side? > > > Thanks, > > Eduardo > > > -- > > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-- Regards, Arstan Jusupov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120414/540eb7a6/attachment.htm>