[asterisk-users] Unicall protocol error. Cause 32776
Roger C. Beraldi Martins
rogerberaldi at gmail.com
Tue Dec 11 10:52:38 CST 2007
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 Telecomprotocolvariant=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.cto 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20071211/39e5f15c/attachment.htm
More information about the asterisk-users
mailing list