Re: [asterisk-users] Unicall + incomplete DNIS on international calls
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 <[EMAIL PROTECTED]> 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] > > 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
[asterisk-users] Unicall + incomplete DNIS on international calls
> > 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] > 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_un
[asterisk-users] Unicall + incomplete DNIS on international calls
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] 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_unical