[asterisk-users] Unicall protocol error. Cause 32776

[Moises Silva]

Yes, was my mistake, just the first pair of bits are changed to 0x0,
that is, if initially is 1001, 0001 is the seize state.

On Dec 14, 2007 1:04 PM, Roger C. Beraldi Martins
<rogerberaldi at gmail.com> wrote:
> Moises,
>
> I was reading about your first reply and you said in the 2nd step:
>
> >
> >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".
> >
>
> If I understood correctly the libmfcr2 must put bits 0000 (Size) to indicate
> it's will dial.
> But at this time on log libunicall put 0001 to Seize:
>
>
> >[Dec 14 09:53:42] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Creating
> a new call with CRN 32769
> >[Dec 14 09:53:42] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 0001  ->
> [1/DIALING /Seize         /Idle         ]
> >[Dec 14 09:53:42] VERBOSE[28143] logger.c:     -- Called g1
>
> After this libunicall set the IDLE (1001) state again:
>
>
> [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 1001  ->
> [1/IDLE    /Idle          /Idle         ]
>
>
> Are this correctly ?
>
>
> Regards,
>
>
>
>  2007/12/14, Roger C. Beraldi Martins <rogerberaldi at gmail.com>:
>
> > Dears,
> >
> > Here is the logs when I put loglevel=255 on unicall.conf, I have use
> max-wait = 10000
> >
> >
> > [Dec 14 09:53:42] DEBUG[28143] chan_unicall.c: unicall_call called - 'g1'
> > [Dec 14 09:53:42] DEBUG[28143] chan_unicall.c: unicall_call caller id -
> '3007'
> > [Dec 14 09:53:42] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Call
> control(1)
> > [Dec 14 09:53:42] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Make
> call
> > [Dec 14 09:53:42] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Creating
> a new call with CRN 32769
> > [Dec 14 09:53:42] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 0001  ->
> [1/DIALING /Seize         /Idle         ]
> > [Dec 14 09:53:42] VERBOSE[28143] logger.c:     -- Called g1
> > [Dec 14 09:53:42] NOTICE[28143] chan_unicall.c: Unicall/1 event Dialing
> > [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1
> seize_ack_wait_expired
> > [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 R2 prot.
> err. [1/DIALING /Seize         /Idle         ] cau
> > se 32776 - Seize ack timed out
> > [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 1001  ->
> [1/IDLE    /Idle          /Idle         ]
> > [Dec 14 09:53:53] NOTICE[28143] chan_unicall.c: Unicall/1 event Protocol
> failure
> > [Dec 14 09:53:53] ERROR[28143] chan_unicall.c: Unicall/1 protocol error.
> Cause 32776
> > [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Channel
> echo cancel
> > [Dec 14 09:53:53] DEBUG[28143] chan_unicall.c: disabled echo cancellation
> on channel 1
> > [Dec 14 09:53:53] WARNING[28143] app_dial.c: Unable to forward voice or
> dtmf
> > [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Channel
> gains
> > [Dec 14 09:53:53] WARNING[28143] chan_unicall.c: MFC/R2 UniCall/1 Channel
> switching
> > [Dec 14 09:53:53] DEBUG[28143] chan_unicall.c: Hangup: channel: 1 index =
> 0, normal = 10, callwait = -1, thirdcall = -1
> > [Dec 14 09:53:53] DEBUG[28143] chan_unicall.c: Updated conferencing on 1,
> with 0 conference users
> > [Dec 14 09:53:53] VERBOSE[28143] logger.c:     -- Hungup 'UniCall/1-1'
> > [Dec 14 09:53:53] VERBOSE[28143] logger.c:   == Everyone is busy/congested
> at this time (1:0/0/1)
> > [Dec 14 09:53:53] DEBUG[28143] app_macro.c: Executed application: Dial
> >
> >
> > Best Regards,
> >
> >
> >
> > --
> >
> > Atenciosamente,
> >
> > Roger C. Beraldi Martins
> > Fone: 41-8828-7068
>
>
>
>
> --
> 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."