[asterisk-users] Unicall protocol error. Cause 32776
Moises Silva
moises.silva at gmail.com
Tue Dec 11 14:48:34 CST 2007
Roger,
You can try to pass the protocolvariant like this:
protocolvariant=br,20,4,x,max-seize-wait-ack=3000
This deserves a little bit of more explanation.
br = Brazil
20 = ANI digits
4 = DNIS digits
x = this is just a hack to be able to work with defaults and specify
the next value. protocolvariant expect here a mask of values ( an
integer ), passing NOT an integer but a character x will cause the
defaults to remain.
max-seize-wait-ack = Number of milliseconds to wait for the ACK.
Try incrementing that number to see if works. If does, please post
back results here.
Regards,
On Dec 11, 2007 10:52 AM, Roger C. Beraldi Martins
<rogerberaldi at gmail.com> wrote:
> Moises,
>
> Thank you for your reply and the lesson of MFC/R2 !
>
> My configs for the unicall.conf is:
> [channels]
> language=br
> context=from-pstn
> usecallerid=yes
> hidecallerid=no
> immediate=no
>
> callwaitingcallerid=yes
> threewaycalling=yes
> transfer=yes
> cancallforward=yes
> callreturn=yes
> echocancel=yes
> echocancelwhenbridged=yes
> rxgain=0.0
> txgain=0.0
> faxdetect=both
> loglevel=0
> protocolclass=mfcr2
>
> protocolvariant=br,20,4
> protocolend=cpe
> group=1
> callerid=asreceived
> channel=>1-15
> channel=>17-31
> channel=>32-46
> channel=>48-62
> channel=>63-77
> channel=>79-93
> protocolclass=mfcr2
>
>
> The teleco who provides the links E1s is Brasil Telecom, I use the
> protocolvariant as shown in voip-info.org:
> Brasil Telecom
> protocolvariant=br,20,4
> But I have a question in relation to variable:
> protocolend=co
>
> I was using "=co" and others configs I saw are using "=cpe". I have change
> it, but don't seams to have effect to me.
>
> I read something on the internet which suggested changes in the file mfcr2.c
> to correct variables of timing. I believe that that should be the way to
> solution, but I do not feel safe to do this changes.
>
> Some research later, I saw information that in future versions of
> libunicall would not be necessary to rebuild lib to change parameters of
> timing, but I believe that's not implemented yet.
>
> How I can set a time of increased response of "Seize ACK" ?
>
> Thank you !
>
> 2007/12/11, Moises Silva <moises.silva at gmail.com>:
> > Roger,
> >
> > The "seize ack timeout" problem is because libmfcr2 is expecting a
> > response ( an ACK ) from the far end and it does not arrive in a R2
> > variant dependant amount of time. Which protocolvariant do you have
> > configured in unicall.conf?
> >
> > This is how the process to start a call goes:
> >
> > 1. When you Dial(Unicall/blah), Asterisk will ask chan_unicall.c to
> > initiate the call. chan_unicall will ask libunicall to start the call,
> > and libunicall will ask libmfcr2 to start the call.
> >
> > 2. libmfcr2 will set the ABCD bits to 0x0 (000) ( normally the ABCD
> > bits are in Idle 1001 ). Setting the ABCD bits to 0x0 is our way to
> > tell the far end ( the telco ) that we want to start a call, this is
> > known as the "Seize".
> >
> > 3. The far end should detect this bit pattern change and answer with a
> > "Seize ACK" ( ABCD bits in 0xC ), in this case, libmfcr2 does not
> > receive the expected ACK in 2000ms unless you are in Kuwait ( 4000ms )
> > or Nigeria (10000ms ).
> >
> > So, let us know your R2 variant, probably your country require more
> > time to wait for the Seize ACK.
> >
> > Regards,
> >
> > Moisés Silva
> >
> >
> > On Dec 11, 2007 7:03 AM, Roger C. Beraldi Martins
> > <rogerberaldi at gmail.com> wrote:
> > > Dears,
> > >
> > > After having set up the board Digium TE420 to receive 3 E1s, I can
> receive
> > > calls without difficulties. As you can see in the log below:
> > >
> > > -- Executing [5908 at from-pstn:1] NoOp("UniCall/14-1", "Catch-All DID
> Match
> > > - Found 5908 - You probably want a DID for this.") in new stack
> > > -- Executing [5908 at from-pstn :2] Goto("UniCall/14-1",
> "ext-did|s|1") in
> > > new stack
> > > -- Goto (ext-did,s,1)
> > > -- Executing [s at ext-did:1] Set("UniCall/14-1", "__FROM_DID=s") in
> new
> > > stack
> > > -- Executing [s at ext-did:2] GotoIf("UniCall/14-1", "0 ?cidok") in
> new
> > > stack
> > > -- Executing [s at ext-did:3] Set("UniCall/14-1",
> > > "CALLERID(name)=4133602900") in new stack
> > > -- Executing [s at ext-did:4] NoOp("UniCall/14-1", "CallerID is
> > > "4133602900" <4133602900>") in new stack
> > > -- Executing [s at ext-did:5] Goto("UniCall/14-1", "ivr-3|s|1") in new
> > > stack
> > > -- Goto (ivr-3,s,1)
> > > *snip*
> > > -- Executing [s at ivr-3:10] BackGround("UniCall/14-1",
> "custom/celia") in
> > > new stack
> > > -- <UniCall/14-1> Playing 'custom/celia' (language 'br')
> > > -- Executing [h at ivr-3:1] Hangup("UniCall/14-1", "") in new stack
> > > -- Hungup 'UniCall/14-1'
> > > -- Unicall/14 released
> > >
> > >
> > >
> > > Now I am having problems to make calls using the libunicall. The problem
> is
> > > clear in this line of the full log:
> > > [Dec 11 10:03:54] ERROR[12935] chan_unicall.c: Unicall/1 protocol
> error.
> > > Cause 32776
> > >
> > > Searching for the error I discovered it is "Seize ack timed out", but I
> do
> > > not know exactly of what it means or how to fix it. Here is de version
> of
> > > softwares/libs I have use (
> > > http://www.voip-info.org/wiki/view/Asterisk+MFC+R2 ).
> > >
> > > asterisk-1.4.9
> > > spandsp-0.0.4
> > > unicall-0.0.5pre1
> > > zaptel-1.4.4
> > >
> > > I already try using asterisk 1.4.10 but the comportment is the same. I
> > > don't believe the problem is in asterisk. I think my configs are
> correctly
> > > but not sure. Attached in text file follow the tests I have done using
> > > testunicall, config files from zaptel.conf and unicall.conf I using on
> this
> > > solution. More logs is in the same file.
> > >
> > > This can be caused by a problem with signaling between my settings and
> the
> > > standard of telephony service ?
> > >
> > > I'm using FreePBX with a Custon Trunk (Custon String Dial: UniCall/g1),
> my
> > > extensions_aditional has
> > > the "OUT_3 = AMP:UniCall/g1" and "OUTMAXCHANS_3 = 10".
> > >
> > > Someone has already gone through a problem like this ? I would be
> grateful
> > > if received suggestions to correct it.
> > >
> > > Log Full:
> > >
> > > [Dec 11 10:03:51] VERBOSE[12935] logger.c: -- Executing
> > > [s at macro-dialout-trunk :32] Dial("SIP/2290-09b18a68", "UniCall/g1|300|")
> in
> > > new stack
> > > [Dec 11 10:03:51] DEBUG[12935] chan_unicall.c: unicall_call called -
> 'g1'
> > > [Dec 11 10:03:51] DEBUG[12935] chan_unicall.c: unicall_call caller id -
> > > '2290'
> > > [Dec 11 10:03:51] VERBOSE[12935] logger.c: -- Called g1
> > > [Dec 11 10:03:51] NOTICE[12935] chan_unicall.c: Unicall/1 event Dialing
> > > [Dec 11 10:03:54] NOTICE[12935] chan_unicall.c: Unicall/1 event Protocol
> > > failure
> > > [Dec 11 10:03:54] ERROR[12935] chan_unicall.c: Unicall/1 protocol error.
> > > Cause 32776
> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: disabled echo
> cancellation on
> > > channel 1
> > > [Dec 11 10:03:54] WARNING[12935] app_dial.c: Unable to forward voice or
> dtmf
> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: Hangup: channel: 1 index
> = 0,
> > > normal = 10, callwait = -1, thirdcall = -1
> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: Updated conferencing on
> 1,
> > > with 0 conference users
> > > [Dec 11 10:03:54] VERBOSE[12935] logger.c: -- Hungup 'UniCall/1-1'
> > > [Dec 11 10:03:54] VERBOSE[12935] logger.c: == Everyone is
> busy/congested
> > > at this time (1:0/0/1)
> > >
> > >
> > >
> > >
> > > --
> > > Atenciosamente,
> > >
> > > Roger C. Beraldi Martins
> > > Fone: 41-8828-7068
> > > _______________________________________________
> > > --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
> > >
> >
> >
> >
> > --
> > "Within C++, there is a much smaller and cleaner language struggling
> > to get out."
> >
> > _______________________________________________
> > --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
> >
>
>
>
> --
> Atenciosamente,
>
> Roger C. Beraldi Martins
> Fone: 41-8828-7068
> _______________________________________________
> --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
>
--
"Within C++, there is a much smaller and cleaner language struggling
to get out."
More information about the asterisk-users
mailing list