thr3ads.net - asterisk users - [asterisk-users] Unicall protocol error. Cause 32776 [Dec 2007]

If this information is useful, please help other people find it:
Share via:

Roger C. Beraldi Martins

2007-Dec-11 13:03 UTC

[asterisk-users] Unicall protocol error. Cause 32776

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071211/28ecf21d/attachment.htm
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: details.txt
Url:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071211/28ecf21d/attachment.txt

Moises Silva

2007-Dec-11 15:26 UTC

head link

[asterisk-users] Unicall protocol error. Cause 32776

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

Luis Antonio Prata Barbosa

2007-Dec-13 16:04 UTC

head link

[asterisk-users] Unicall protocol error. Cause 32776

Beraldi,

Do you have unused links


2007/12/11, Roger C. Beraldi Martins <rogerberaldi at
gmail.com>:>
> 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
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071213/b387004a/attachment.htm

Reasonably Related Threads

Search for more reasonably related threads

asterisk users - Dec 2007 - Unicall protocol error. Cause 32776

[asterisk-users] Unicall protocol error. Cause 32776

[asterisk-users] Unicall protocol error. Cause 32776

[asterisk-users] Unicall protocol error. Cause 32776

Reasonably Related Threads