[asterisk-users] Unicall protocol error. Cause 32776

Moises Silva moises.silva at gmail.com
Thu Dec 13 08:06:08 CST 2007 

As Steve said, put loglevel=255 in unicall.conf to have more details,
please post them here and I will review them.

On Dec 13, 2007 5:02 AM, Roger C. Beraldi Martins
<rogerberaldi at gmail.com> wrote:
> Moises,
>
> I try put the line exactly like you send me, saw the time wait getting
> longer with the parameter you describe to increment. But the error is the
> same as you can see in logs.
>
> Has other way to solve this problem, may I question to my telephony service
> de time it's need to send back the ACK ?
>
> May the libmfcr2 does not receive the expected bit pattern for the ACK ?
>
> FULL LOG:
>
> without max-seize-wait-ack
>
> [Dec 13 08:32:09] VERBOSE[3798] logger.c:     -- Called g1
> [Dec 13 08:32:09] NOTICE[3798] chan_unicall.c: Unicall/1 event Dialing
> [Dec 13 08:32:11] NOTICE[3798] chan_unicall.c: Unicall/1 event Protocol
> failure
> [Dec 13 08:32:11] ERROR[3798] chan_unicall.c: Unicall/1 protocol error.
> Cause 32776
>
> max-seize-wait-ack = 5000
>
> [Dec 13 08:43:54] DEBUG[4845] chan_unicall.c: unicall_call called - 'g1'
> [Dec 13 08:43:54] NOTICE[4845] chan_unicall.c: Unicall/1 event Dialing
> [Dec 13 08:43:59] NOTICE[4845] chan_unicall.c: Unicall/1 event
> Protocolfailure
> [Dec 13 08:43:59] ERROR[4845] chan_unicall.c: Unicall/1 protocol error.
> Cause 32776
>
> max-seize-wait-ack = 10000
>
> [Dec 13 08:39:41] VERBOSE[4494] logger.c:     -- Called g1
> [Dec 13 08:39:41] NOTICE[4494] chan_unicall.c: Unicall/1 event Dialing
> [Dec 13 08:39:51] NOTICE[4494] chan_unicall.c: Unicall/1 event Protocol
> failure
> [Dec 13 08:39:51] ERROR[4494] chan_unicall.c: Unicall/1 protocol error.
> Cause 32776
>
> max-seize-wait-ack = 20000
>
> [Dec 13 08:36:18] VERBOSE[4145] logger.c:     -- Called g1
> [Dec 13 08:36:18] NOTICE[4145] chan_unicall.c: Unicall/1 event Dialing
> [Dec 13 08:36:38] NOTICE[4145] chan_unicall.c: Unicall/1 event Protocol
> failure
> [Dec 13 08:36:38] ERROR[4145] chan_unicall.c: Unicall/1 protocol error.
> Cause 32776
>
> max-seize-wait-ack = 50000
>
> ...
> ...
> ...
> ...
>
>
> Best Regards,
>
>
> 2007/12/11, Moises Silva <moises.silva at gmail.com>:
> > 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."
> >
> > _______________________________________________
> > --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