Moises,<br><br>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.<br><br>Has other way to solve this problem, may I question to my telephony service de time it's need to send back the ACK ?
<br><br>May the libmfcr2 does not receive the expected bit pattern for the ACK ?<br><br>FULL LOG:<br><br>without max-seize-wait-ack<br><br>[Dec 13 08:32:09] VERBOSE[3798] logger.c: -- Called g1<br>[Dec 13 08:32:09] NOTICE[3798] chan_unicall.c: Unicall/1 event Dialing
<br>[Dec 13 08:32:11] NOTICE[3798] chan_unicall.c: Unicall/1 event Protocol failure<br>[Dec 13 08:32:11] ERROR[3798] chan_unicall.c: Unicall/1 protocol error. Cause 32776<br><br>max-seize-wait-ack = 5000<br><br>[Dec 13 08:43:54] DEBUG[4845] chan_unicall.c: unicall_call called - 'g1'
<br>[Dec 13 08:43:54] NOTICE[4845] chan_unicall.c: Unicall/1 event Dialing<br>[Dec 13 08:43:59] NOTICE[4845] chan_unicall.c: Unicall/1 event Protocolfailure<br>[Dec 13 08:43:59] ERROR[4845] chan_unicall.c: Unicall/1 protocol error. Cause 32776
<br><br>max-seize-wait-ack = 10000<br><br>[Dec 13 08:39:41] VERBOSE[4494] logger.c: -- Called g1<br>[Dec 13 08:39:41] NOTICE[4494] chan_unicall.c: Unicall/1 event Dialing<br>[Dec 13 08:39:51] NOTICE[4494] chan_unicall.c: Unicall/1 event Protocol failure
<br>[Dec 13 08:39:51] ERROR[4494] chan_unicall.c: Unicall/1 protocol error. Cause 32776<br><br>max-seize-wait-ack = 20000<br><br>[Dec 13 08:36:18] VERBOSE[4145] logger.c: -- Called g1<br>[Dec 13 08:36:18] NOTICE[4145] chan_unicall.c: Unicall/1 event Dialing
<br>[Dec 13 08:36:38] NOTICE[4145] chan_unicall.c: Unicall/1 event Protocol failure<br>[Dec 13 08:36:38] ERROR[4145] chan_unicall.c: Unicall/1 protocol error. Cause 32776<br><br>max-seize-wait-ack = 50000<br><br>...<br>...
<br>...<br>...<br><br><br>Best Regards,<br><br><br><div><span class="gmail_quote">2007/12/11, Moises Silva <<a href="mailto:moises.silva@gmail.com">moises.silva@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Roger,<br><br>You can try to pass the protocolvariant like this:<br><br>protocolvariant=br,20,4,x,max-seize-wait-ack=3000<br><br>This deserves a little bit of more explanation.<br><br>br = Brazil<br>20 = ANI digits<br>4 = DNIS digits
<br>x = this is just a hack to be able to work with defaults and specify<br>the next value. protocolvariant expect here a mask of values ( an<br>integer ), passing NOT an integer but a character x will cause the<br>defaults to remain.
<br>max-seize-wait-ack = Number of milliseconds to wait for the ACK.<br><br>Try incrementing that number to see if works. If does, please post<br>back results here.<br><br>Regards,<br><br><br>On Dec 11, 2007 10:52 AM, Roger C. Beraldi Martins
<br><<a href="mailto:rogerberaldi@gmail.com">rogerberaldi@gmail.com</a>> wrote:<br>> Moises,<br>><br>> Thank you for your reply and the lesson of MFC/R2 !<br>><br>> My configs for the unicall.conf is:
<br>> [channels]<br>> language=br<br>> context=from-pstn<br>> usecallerid=yes<br>> hidecallerid=no<br>> immediate=no<br>><br>> callwaitingcallerid=yes<br>> threewaycalling=yes<br>> transfer=yes
<br>> cancallforward=yes<br>> callreturn=yes<br>> echocancel=yes<br>> echocancelwhenbridged=yes<br>> rxgain=0.0<br>> txgain=0.0<br>> faxdetect=both<br>> loglevel=0<br>> protocolclass=mfcr2<br>>
<br>> protocolvariant=br,20,4<br>> protocolend=cpe<br>> group=1<br>> callerid=asreceived<br>> channel=>1-15<br>> channel=>17-31<br>> channel=>32-46<br>> channel=>48-62<br>> channel=>63-77
<br>> channel=>79-93<br>> protocolclass=mfcr2<br>><br>><br>> The teleco who provides the links E1s is Brasil Telecom, I use the<br>> protocolvariant as shown in <a href="http://voip-info.org">voip-info.org
</a>:<br>> Brasil Telecom<br>> protocolvariant=br,20,4<br>> But I have a question in relation to variable:<br>> protocolend=co<br>><br>> I was using "=co" and others configs I saw are using "=cpe". I have change
<br>> it, but don't seams to have effect to me.<br>><br>> I read something on the internet which suggested changes in the file mfcr2.c<br>> to correct variables of timing. I believe that that should be the way to
<br>> solution, but I do not feel safe to do this changes.<br>><br>> Some research later, I saw information that in future versions of<br>> libunicall would not be necessary to rebuild lib to change parameters of
<br>> timing, but I believe that's not implemented yet.<br>><br>> How I can set a time of increased response of "Seize ACK" ?<br>><br>> Thank you !<br>><br>> 2007/12/11, Moises Silva <
<a href="mailto:moises.silva@gmail.com">moises.silva@gmail.com</a>>:<br>> > Roger,<br>> ><br>> > The "seize ack timeout" problem is because libmfcr2 is expecting a<br>> > response ( an ACK ) from the far end and it does not arrive in a R2
<br>> > variant dependant amount of time. Which protocolvariant do you have<br>> > configured in unicall.conf?<br>> ><br>> > This is how the process to start a call goes:<br>> ><br>> > 1. When you Dial(Unicall/blah), Asterisk will ask chan_unicall.c to
<br>> > initiate the call. chan_unicall will ask libunicall to start the call,<br>> > and libunicall will ask libmfcr2 to start the call.<br>> ><br>> > 2. libmfcr2 will set the ABCD bits to 0x0 (000) ( normally the ABCD
<br>> > bits are in Idle 1001 ). Setting the ABCD bits to 0x0 is our way to<br>> > tell the far end ( the telco ) that we want to start a call, this is<br>> > known as the "Seize".<br>> >
<br>> > 3. The far end should detect this bit pattern change and answer with a<br>> > "Seize ACK" ( ABCD bits in 0xC ), in this case, libmfcr2 does not<br>> > receive the expected ACK in 2000ms unless you are in Kuwait ( 4000ms )
<br>> > or Nigeria (10000ms ).<br>> ><br>> > So, let us know your R2 variant, probably your country require more<br>> > time to wait for the Seize ACK.<br>> ><br>> > Regards,<br>> >
<br>> > Moisés Silva<br>> ><br>> ><br>> > On Dec 11, 2007 7:03 AM, Roger C. Beraldi Martins<br>> > <<a href="mailto:rogerberaldi@gmail.com">rogerberaldi@gmail.com</a>> wrote:<br>> > > Dears,
<br>> > ><br>> > > After having set up the board Digium TE420 to receive 3 E1s, I can<br>> receive<br>> > > calls without difficulties. As you can see in the log below:<br>> > ><br>> > > -- Executing [
5908@from-pstn:1] NoOp("UniCall/14-1", "Catch-All DID<br>> Match<br>> > > - Found 5908 - You probably want a DID for this.") in new stack<br>> > > -- Executing [5908@from-pstn
:2] Goto("UniCall/14-1",<br>> "ext-did|s|1") in<br>> > > new stack<br>> > > -- Goto (ext-did,s,1)<br>> > > -- Executing [s@ext-did:1] Set("UniCall/14-1", "__FROM_DID=s") in
<br>> new<br>> > > stack<br>> > > -- Executing [s@ext-did:2] GotoIf("UniCall/14-1", "0 ?cidok") in<br>> new<br>> > > stack<br>> > > -- Executing [s@ext-did
:3] Set("UniCall/14-1",<br>> > > "CALLERID(name)=4133602900") in new stack<br>> > > -- Executing [s@ext-did:4] NoOp("UniCall/14-1", "CallerID is<br>> > > "4133602900" <4133602900>") in new stack
<br>> > > -- Executing [s@ext-did:5] Goto("UniCall/14-1", "ivr-3|s|1") in new<br>> > > stack<br>> > > -- Goto (ivr-3,s,1)<br>> > > *snip*<br>> > > -- Executing [
s@ivr-3:10] BackGround("UniCall/14-1",<br>> "custom/celia") in<br>> > > new stack<br>> > > -- <UniCall/14-1> Playing 'custom/celia' (language 'br')<br>> > > -- Executing [
h@ivr-3:1] Hangup("UniCall/14-1", "") in new stack<br>> > > -- Hungup 'UniCall/14-1'<br>> > > -- Unicall/14 released<br>> > ><br>> > ><br>> > >
<br>> > > Now I am having problems to make calls using the libunicall. The problem<br>> is<br>> > > clear in this line of the full log:<br>> > > [Dec 11 10:03:54] ERROR[12935] chan_unicall.c: Unicall/1 protocol
<br>> error.<br>> > > Cause 32776<br>> > ><br>> > > Searching for the error I discovered it is "Seize ack timed out", but I<br>> do<br>> > > not know exactly of what it means or how to fix it. Here is de version
<br>> of<br>> > > softwares/libs I have use (<br>> > > <a href="http://www.voip-info.org/wiki/view/Asterisk+MFC+R2">http://www.voip-info.org/wiki/view/Asterisk+MFC+R2</a> ).<br>> > ><br>> > >
asterisk-1.4.9<br>> > > spandsp-0.0.4<br>> > > unicall-0.0.5pre1<br>> > > zaptel-1.4.4<br>> > ><br>> > > I already try using asterisk 1.4.10 but the comportment is the same. I
<br>> > > don't believe the problem is in asterisk. I think my configs are<br>> correctly<br>> > > but not sure. Attached in text file follow the tests I have done using<br>> > > testunicall, config files from
zaptel.conf and unicall.conf I using on<br>> this<br>> > > solution. More logs is in the same file.<br>> > ><br>> > > This can be caused by a problem with signaling between my settings and<br>
> the<br>> > > standard of telephony service ?<br>> > ><br>> > > I'm using FreePBX with a Custon Trunk (Custon String Dial: UniCall/g1),<br>> my<br>> > > extensions_aditional has
<br>> > > the "OUT_3 = AMP:UniCall/g1" and "OUTMAXCHANS_3 = 10".<br>> > ><br>> > > Someone has already gone through a problem like this ? I would be<br>> grateful<br>> > > if received suggestions to correct it.
<br>> > ><br>> > > Log Full:<br>> > ><br>> > > [Dec 11 10:03:51] VERBOSE[12935] logger.c: -- Executing<br>> > > [s@macro-dialout-trunk :32] Dial("SIP/2290-09b18a68", "UniCall/g1|300|")
<br>> in<br>> > > new stack<br>> > > [Dec 11 10:03:51] DEBUG[12935] chan_unicall.c: unicall_call called -<br>> 'g1'<br>> > > [Dec 11 10:03:51] DEBUG[12935] chan_unicall.c: unicall_call caller id -
<br>> > > '2290'<br>> > > [Dec 11 10:03:51] VERBOSE[12935] logger.c: -- Called g1<br>> > > [Dec 11 10:03:51] NOTICE[12935] chan_unicall.c: Unicall/1 event Dialing<br>> > > [Dec 11 10:03:54] NOTICE[12935] chan_unicall.c: Unicall/1 event Protocol
<br>> > > failure<br>> > > [Dec 11 10:03:54] ERROR[12935] chan_unicall.c: Unicall/1 protocol error.<br>> > > Cause 32776<br>> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: disabled echo
<br>> cancellation on<br>> > > channel 1<br>> > > [Dec 11 10:03:54] WARNING[12935] app_dial.c: Unable to forward voice or<br>> dtmf<br>> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: Hangup: channel: 1 index
<br>> = 0,<br>> > > normal = 10, callwait = -1, thirdcall = -1<br>> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: Updated conferencing on<br>> 1,<br>> > > with 0 conference users<br>> > > [Dec 11 10:03:54] VERBOSE[12935]
logger.c: -- Hungup 'UniCall/1-1'<br>> > > [Dec 11 10:03:54] VERBOSE[12935] logger.c: == Everyone is<br>> busy/congested<br>> > > at this time (1:0/0/1)<br>> > ><br>> > >
<br>> > ><br>> > ><br>> > > --<br>> > > Atenciosamente,<br>> > ><br>> > > Roger C. Beraldi Martins<br>> > > Fone: 41-8828-7068<br>> > > _______________________________________________
<br>> > > --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>> > ><br>> > > asterisk-users mailing list<br>> > > To UNSUBSCRIBE or update options visit:
<br>> > > <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>> > ><br>> ><br>> ><br>> ><br>> > --<br>
> > "Within C++, there is a much smaller and cleaner language struggling<br>> > to get out."<br>> ><br>> > _______________________________________________<br>> > --Bandwidth and Colocation Provided by
<a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>> ><br>> > asterisk-users mailing list<br>> > To UNSUBSCRIBE or update options visit:<br>> > <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">
http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>> ><br>><br>><br>><br>> --<br>> Atenciosamente,<br>><br>> Roger C. Beraldi Martins<br>> Fone: 41-8828-7068<br>> _______________________________________________
<br>> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>><br>> asterisk-users mailing list<br>> To UNSUBSCRIBE or update options visit:<br>>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>><br><br><br><br>--<br>"Within C++, there is a much smaller and cleaner language struggling
<br>to get out."<br><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br><br>asterisk-users mailing list
<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br><br clear="all"><br>
-- <br>Atenciosamente,<br><br>Roger C. Beraldi Martins<br>Fone: 41-8828-7068