[asterisk-users] Unicall protocol error. Cause 32776

Tue Dec 11 09:26:42 CST 2007

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."