[asterisk-users] Unicall protocol error. Cause 32776
Roger C. Beraldi Martins
rogerberaldi at gmail.com
Thu Dec 13 05:02:20 CST 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20071213/0abc5ed5/attachment.htm
More information about the asterisk-users
mailing list