[asterisk-users] Unicall + incomplete DNIS on international calls
Moises Silva
moises.silva at gmail.com
Fri Apr 4 09:27:23 CDT 2008
Hello Ivan,
I don't see nothing "wrong" in terms of signaling. When your side
(Asterisk/Unicall) request ANI, the other end answer with the signal
F, which means "No More ANI", hence you receive an empty ANI string.
When your side request DNIS, the other end does not answer in several
seconds, which means 'No More DNIS' then your side timesout and resume
the signaling to proceed to Answer if appropriate.
You should definitely setup a call with Telmex support and see what do
they see on their side. No timer tweaking will help for the ANI here
because it is pretty clear they are sending "End of ANI" signal 'F'.
In the case of DNIS I also think the timer will not help, you already
waited 15 seconds to timeout for DNIS, if they don't send DNIS in 15
seconds is pretty obvious they are not going to send any.
Moy
On Tue, Apr 1, 2008 at 4:40 PM, Iván Reyes Tejera
<it.ivanreyes at gmail.com> wrote:
> > Hello everybody, i'm from Mexico, at the time i´m working on a production
> server with asterisk 1.2.25 + spandsp-0.0.4 +
> libmfcr2-0.0.3+libsupertone-0.0.2+libunicall-0.0.3 and zaptel-1.2.22. I
> installed this version of astunicall that i downloaded from
> http://www.moythreads.com/astunicall/
> >
> > Everything works fine, i'm able to make outgoing calls and recive incoming
> calls with all ANI and DNIS digits, except for International incoming call.
> My phone provider(Telmex) gives me 10 digits of ANI and 4 digits of DNIS,
> that i´ve configured on my unicall.conf. My main issue becomes when i recive
> an internationall incoming call, there is no ANI, appears with only one
> digit instead four, and that digit it's always a number 1( i attach unicall
> log).
> >
> > I already talked with my phone provider about this issue, and, as they
> told me, all DNIS and ANI of international incoming calls are just bypassed
> by them directly to my server. They mentioned something about timers that
> may avoid my server to recive all values (DNIS and ANI), but i'm not quite
> sure about this. On my file unicall.conf i added some timers that moises
> commented on his forum.
> >
> > Any clue what would be the reason of my issue ?
> >
> > Here are my files:
> > ----------------------
> > unicall.conf
> > ----------------------
> > [channels]
> > language=en
> > context=from-pstn
> > usecallerid=yes
> > hidecallerid=no
> > callwaitingcallerid=yes
> > threewaycalling=yes
> > transfer=yes
> > cancallforward=yes
> > callreturn=yes
> > echocancel=yes
> > echocancelwhenbridged=no
> > echotraining=800
> > relaxdtmf=no
> > rxgain=0
> > txgain=0
> > group=1
> > callgroup=0
> > pickupgroup=0
> > immediate=no
> > callerid=asreceived
> > amaflags=default
> > musiconhold=default
> > protocolclass=mfcr2
> >
> protocolvariant=mx,10,4,7,t1=15000,t2=24000,t3=15000,max-seize-wait-ack=2000
> > channel=1-10
> > loglevel=255
> >
> >
> > ------------------
> > zapata.conf
> > -------------------
> > [channels]
> > context=default
> > usecallerid=yes
> > hidecallerid=no
> > callwaiting=yes
> > usecallingpres=yes
> > callwaitingcallerid=yes
> > threewaycalling=yes
> > transfer=yes
> > canpark=yes
> > cancallforward=yes
> > callreturn=yes
> > echocancel=no
> > echocancelwhenbridged=no
> > echotraining=no
> > relaxdtmf=yes
> > rxgain=0.0
> > txgain=0.0
> > group=1
> > callgroup=1
> > pickupgroup=1
> > immediate=no
> >
> > -----------------------
> > zaptel.conf
> > -----------------------
> > loadzone=us
> > defaultzone=us
> >
> > #Sangoma A101 port 1 [slot:0 bus:10 span:1] <wanpipe1>
> > span=1,1,0,cas,hdb3
> > cas=1-10:1101
> > dchan=16
> >
> >
> > -------------------------
> > DEBUG UNICALL
> > ---------------------------
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 0001
> [1/IDLE /Idle /Idle ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 Detected
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 Creating a
> new call with CRN 32769
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 1101 ->
> [2/DETECTED/Seize ack /Seize ack ]
> > Mar 31 13:10:35 NOTICE[14902] chan_unicall.c: Unicall/8 event Detected
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 1 on
> [2/DETECTED/Seize ack /Seize ack ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 6 on ->
> [2/DETECTED/Group C /Category req ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 1
> off [2/DETECTED/Group C /Category req ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 6 off ->
> [2/DETECTED/Group C /Category req ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 2 on
> [2/DETECTED/Group C /Category req ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 1 on ->
> [2/DETECTED/Group C /ANI request ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 2
> off [2/DETECTED/Group C /ANI request ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 1 off ->
> [2/DETECTED/Group C /ANI request ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- F on
> [2/DETECTED/Group C /ANI request ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 5 on ->
> [2/DETECTED/Group A /DNIS request ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- F
> off [2/DETECTED/Group A /DNIS request ]
> > Mar 31 13:10:35 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 5 off ->
> [2/DETECTED/Group A /DNIS request ]
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 3 on ->
> [2/DETECTED/Group B /Go to grp II ]
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 3 off ->
> [2/DETECTED/Group B /Go to grp II ]
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 2 on
> [2/DETECTED/Group B /Go to grp II ]
> > Mar 31 13:10:50 NOTICE[14902] chan_unicall.c: Unicall/8 event Offered
> > Mar 31 13:10:50 NOTICE[14902] chan_unicall.c: CRN 32769 - Offered on
> channel 0 (ANI: , DNIS: 1, Cat: 1) <---------- The values of ANI and DNIS
> are incorrect
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 Call
> control(5)
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 Accept call
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 1 on ->
> [2/OFFERED /Group B /Accepted Paid]
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 <- 2
> off [2/OFFERED /Group B /Accepted Paid]
> > Mar 31 13:10:50 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 1 off ->
> [2/OFFERED /Group B /Accepted Paid]
> > Mar 31 13:10:51 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 Answer guard
> expired
> > Mar 31 13:10:51 NOTICE[14902] chan_unicall.c: Unicall/8 event Accepted
> > Mar 31 13:10:51 DEBUG[14902] chan_unicall.c: MFC/R2 UniCall/8 Channel
> gains
> > Mar 31 13:10:51 VERBOSE[31370] logger.c: -- Executing
> Dial("UniCall/8-1", "IAX2/ast2:iaxpalancar at 192.168.1.20/1||TtWw") in new
> stack
> > .
> > .
> > .
> > .....everything continues normally
> >
> >
> >
> >
> > Thanks in advice for your time.
> >
> > Ivan Reyes Tejera
> >
> >
> >
> >
> >
> >
> >
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire
More information about the asterisk-users
mailing list