Re: [Asterisk-Users] Unicall acting really funny
Hi Joao, What is the T3 timeout set to? If it is short, try making it something like 15000 (it is in milliseconds). Your T3 timeout problem could be due to slow reponses from some destinations. For your second issue, the following is definitely a protocol error: UniCall/1 - 1 off [2/ 40/Group II /Category ] The last tone has done off, and we are waiting for answer UniCall/1 - 0111 [1/ 200/Await answer /Category ] Got the answer UniCall/1 - 0011 [1/ 400/Answered /Category ] Three seconds later we have a seize in the answered state. That is not right. Some people getting billing pulses in the answer state. Those usually look like the line momentarily clearing. You can set a timer in my software to ride over those. I don't know of systems that pulse the seize condition using the answer state. Steve Joao Mesquita wrote: Hello Steve, Thank you for being so active helping people with Unicall problems, I am sure a lot of us appreciate this. I could tweak a little bit more with your software versions from the download site and I got half of the problems solved. Now I am able to set the loglevel to 255 and that gives me a whole lot more tools to work with. I am now also able to reload the chan_unicall.so module correctly without having to restart asterisk. I am sorry for the lame mistakes. I am pretty sure that the CRC4 was not the problem because the FAS increased with CRC4 on and I got a RED signal on the board. Logs on that are printed below. That leaves me with 2 problems and 1 warning. The first problem is that some phones on the office (the Siemens Euroset family) are not able to complete calls from the Highpath to the asterisk (dialing to a SIP extension). I got a T3 timed out message and that's where the call hangs. I could get to this conclusion because all other phone models I tested with completed the calls just fine. I don't know how many other phone models on the office present the same problem. Logs are below. The second problem is when I try to pickup a call coming from the Highpath and dial the extension number dialed to the PSTN E1. The call does not complete although it gets to ring on the destination (on this case my mobile phone) once. The most funky part of this is that this happens MOST of the times, but not all of them and this is what was suggesting a CRC4 problem (I guess). The verbose version of the log files are below. The last is a warning might be related to the second problem. Every time I make a call from a SIP endpoint to the PSTN using my PSTN E1 and the PSTN phone disconnects the call, I get an cause 32773 - Unexpected CAS bit pattern message. I call this a warning because I could not relate any real problem on the calls with that. Logs on that are also below. Thank you in advance, Mesquita * CRC4 / RED SIGNAL LOGS *** asterisk-test:~# cat /proc/zaptel/1 Span 1: Tor2/0/1 Tormenta 2 (PCI) Quad E1 Card 0 Span 1 HDB3//CRC4 RED CRC4 error count: 986 FAS error count: 192 1 Tor2/0/1/1 CAS asterisk-test:~# cat /proc/zaptel/2 Span 2: Tor2/0/2 Tormenta 2 (PCI) Quad E1 Card 0 Span 2 HDB3//CRC4 32 Tor2/0/2/1 CAS 33 Tor2/0/2/2 CAS -- Executing Dial(SIP/teste-4640, Unicall/g1/94109570) in new stack Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Call control(1) Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Make call Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:1077 unicall_call: Make call failed - Blocked -- Couldn't call g1/94109570 Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Channel gains Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Channel switching -- Hungup 'UniCall/1-1' == Everyone is busy/congested at this time (0:0/0/0) ** FIRST PROBLEM LOGS * asterisk-test:~# cat /proc/zaptel/1 Span 1: Tor2/0/1 Tormenta 2 (PCI) Quad E1 Card 0 Span 1 HDB3/ ClockSource 1 Tor2/0/1/1 CAS (In use) 2 Tor2/0/1/2 CAS (In use) asterisk-test:~# cat /etc/asterisk/extensions.conf (snip) [from-e1-interno] exten = _X.,1,Answer exten = _X.,n,Dial(SIP/teste) exten = _X.,n,Hangup Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 - 0001 [1/ 1/Idle /Idle ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 Detected Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 Making a new call with CRN 32769 Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 1101 - [2/ 2/Idle /Idle ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:2644 handle_uc_event: Unicall/39 event Detected Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2
Re: [Asterisk-Users] Unicall acting really funny
Hello Steve, Thank you for being so active helping people with Unicall problems, I am sure a lot of us appreciate this. I could tweak a little bit more with your software versions from the download site and I got half of the problems solved. Now I am able to set the loglevel to 255 and that gives me a whole lot more tools to work with. I am now also able to reload the chan_unicall.so module correctly without having to restart asterisk. I am sorry for the lame mistakes. I am pretty sure that the CRC4 was not the problem because the FAS increased with CRC4 on and I got a RED signal on the board. Logs on that are printed below. That leaves me with 2 problems and 1 warning. The first problem is that some phones on the office (the Siemens Euroset family) are not able to complete calls from the Highpath to the asterisk (dialing to a SIP extension). I got a T3 timed out message and that's where the call hangs. I could get to this conclusion because all other phone models I tested with completed the calls just fine. I don't know how many other phone models on the office present the same problem. Logs are below. The second problem is when I try to pickup a call coming from the Highpath and dial the extension number dialed to the PSTN E1. The call does not complete although it gets to ring on the destination (on this case my mobile phone) once. The most funky part of this is that this happens MOST of the times, but not all of them and this is what was suggesting a CRC4 problem (I guess). The verbose version of the log files are below. The last is a warning might be related to the second problem. Every time I make a call from a SIP endpoint to the PSTN using my PSTN E1 and the PSTN phone disconnects the call, I get an cause 32773 - Unexpected CAS bit pattern message. I call this a warning because I could not relate any real problem on the calls with that. Logs on that are also below. Thank you in advance, Mesquita * CRC4 / RED SIGNAL LOGS *** asterisk-test:~# cat /proc/zaptel/1 Span 1: Tor2/0/1 Tormenta 2 (PCI) Quad E1 Card 0 Span 1 HDB3//CRC4 RED CRC4 error count: 986 FAS error count: 192 1 Tor2/0/1/1 CAS asterisk-test:~# cat /proc/zaptel/2 Span 2: Tor2/0/2 Tormenta 2 (PCI) Quad E1 Card 0 Span 2 HDB3//CRC4 32 Tor2/0/2/1 CAS 33 Tor2/0/2/2 CAS -- Executing Dial(SIP/teste-4640, Unicall/g1/94109570) in new stack Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Call control(1) Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Make call Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:1077 unicall_call: Make call failed - Blocked -- Couldn't call g1/94109570 Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Channel gains Jun 13 03:36:35 WARNING[1874]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/1 Channel switching -- Hungup 'UniCall/1-1' == Everyone is busy/congested at this time (0:0/0/0) ** FIRST PROBLEM LOGS * asterisk-test:~# cat /proc/zaptel/1 Span 1: Tor2/0/1 Tormenta 2 (PCI) Quad E1 Card 0 Span 1 HDB3/ ClockSource 1 Tor2/0/1/1 CAS (In use) 2 Tor2/0/1/2 CAS (In use) asterisk-test:~# cat /etc/asterisk/extensions.conf (snip) [from-e1-interno] exten = _X.,1,Answer exten = _X.,n,Dial(SIP/teste) exten = _X.,n,Hangup Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 - 0001 [1/ 1/Idle /Idle ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 Detected Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 Making a new call with CRN 32769 Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 1101 - [2/ 2/Idle /Idle ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:2644 handle_uc_event: Unicall/39 event Detected Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 - 1 on [2/ 2/Seize ack /Seize ack] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 5 on - [2/ 2/Seize ack /Seize ack] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 - 1 off [2/ 2/Group A /Category req ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 5 off - [2/ 2/Group A /Category req ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 - 1 on [2/ 2/Group A /Category req ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 5 on - [2/ 2/Group A /Category req ] Jun 13 03:24:03 WARNING[1686]: chan_unicall.c:627 unicall_report: MFC/R2 UniCall/39 - 1 off [2/ 2/Group A /ANI request ] Jun 13
Re: [Asterisk-Users] Unicall acting really funny
Dear Moises, Thank you for your reply! I am not sure how to use the testcall tool to debug, but here we go with what I tried. The Main Thread message does never stop showing on the screen, I bet this is not the expected behavior tho. Maybe this can be of any help: asterisk-test:/usr/local/src/libunicall-0.0.3# cat testcall.conf destination-no 1150901010 protocol-class mfcr2 protocol-variant br,10,4 protocol-end cpe on-offered accept circuits 1-10 asterisk-test:/usr/local/src/libunicall-0.0.3# ./testcall Chan 1, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901010' Chan 2, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901011' Chan 3, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901012' Chan 4, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901013' Chan 5, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901014' Chan 6, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901015' Chan 7, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901016' Chan 8, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901017' Chan 9, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901018' Chan 10, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901019' Loading protocol mfcr2 Thread for channel 0 Thread for channel 1 Thread for channel 2 Thread for channel 3 Thread for channel 4 Thread for channel 5 Thread for channel 6 Thread for channel 7 Thread for channel 8 Thread for channel 9 Chan 1: -- Local end unblocked! :-) Chan 1: -- Local end unblocked! :-) Chan 2: -- Local end unblocked! :-) Chan 2: -- Local end unblocked! :-) Chan 3: -- Local end unblocked! :-) Chan 3: -- Local end unblocked! :-) Chan 4: -- Local end unblocked! :-) Chan 4: -- Local end unblocked! :-) Chan 5: -- Local end unblocked! :-) Chan 5: -- Local end unblocked! :-) Chan 6: -- Local end unblocked! :-) Chan 6: -- Local end unblocked! :-) Chan 7: -- Local end unblocked! :-) Chan 7: -- Local end unblocked! :-) Chan 8: -- Local end unblocked! :-) Chan 8: -- Local end unblocked! :-) Chan 9: -- Local end unblocked! :-) Chan 9: -- Local end unblocked! :-) Chan 10: -- Local end unblocked! :-) Chan 10: -- Local end unblocked! :-) Chan 1: -- Far end unblocked! :-) Chan 1: -- Far end unblocked! :-) Chan 1: Initiating call Chan 1: -- Dialing on channel 0 Chan 1: -- Dialing on channel 0 Chan 2: -- Far end unblocked! :-) Chan 2: -- Far end unblocked! :-) Chan 2: Initiating call Chan 2: -- Dialing on channel 0 Chan 2: -- Dialing on channel 0 Chan 3: -- Far end unblocked! :-) Chan 3: -- Far end unblocked! :-) Chan 3: Initiating call Chan 3: -- Dialing on channel 0 Chan 3: -- Dialing on channel 0 Chan 4: -- Far end unblocked! :-) Chan 4: -- Far end unblocked! :-) Chan 4: Initiating call Chan 4: -- Dialing on channel 0 Chan 4: -- Dialing on channel 0 Chan 5: -- Far end unblocked! :-) Chan 5: -- Far end unblocked! :-) Chan 5: Initiating call Chan 5: -- Dialing on channel 0 Chan 5: -- Dialing on channel 0 Chan 6: -- Far end unblocked! :-) Chan 6: -- Far end unblocked! :-) Chan 6: Initiating call Chan 6: -- Dialing on channel 0 Chan 6: -- Dialing on channel 0 Chan 7: -- Far end unblocked! :-) Chan 7: -- Far end unblocked! :-) Chan 7: Initiating call Chan 7: -- Dialing on channel 0 Chan 7: -- Dialing on channel 0 Chan 8: -- Far end unblocked! :-) Chan 8: -- Far end unblocked! :-) Chan 8: Initiating call Chan 8: -- Dialing on channel 0 Chan 8: -- Dialing on channel 0 Chan 9: -- Far end unblocked! :-) Chan 9: -- Far end unblocked! :-) Chan 9: Initiating call Chan 9: -- Dialing on channel 0 Chan 9: -- Dialing on channel 0 Chan 10: -- Far end unblocked! :-) Chan 10: -- Far end unblocked! :-) Chan 10: Initiating call Chan 10: -- Dialing on channel 0 Chan 10: -- Dialing on channel 0 Chan 3: -- Alerting on channel 0 Chan 3: -- Alerting on channel 0 Chan 8: -- Alerting on channel 0 Chan 8: -- Alerting on channel 0 Chan 1: -- Alerting on channel 0 Chan 1: -- Alerting on channel 0 Chan 4: -- Alerting on channel 0 Chan 4: -- Alerting on channel 0 Chan 2: -- Alerting on channel 0 Chan 2: -- Alerting on channel 0 Chan 6: -- Alerting on channel 0 Chan 6: -- Alerting on channel 0 Chan 7: -- Alerting on channel 0 Chan 7: -- Alerting on channel 0 Chan 9: -- Alerting on channel 0 Chan 9: -- Alerting on channel 0 Chan 5: -- Alerting on channel 0 Chan 5: -- Alerting on channel 0 Chan 10: -- Alerting on channel 0 Chan 10: -- Alerting on channel 0 Main thread Main thread Main thread Main thread Main thread Main thread Main thread Main thread Chan 6: -- Protocol failure on channel 0, cause (32773) Unexpected CAS bit pattern Chan 6: -- Protocol
Re: [Asterisk-Users] Unicall acting really funny
Dear Moises, Thank you for your reply! I am not sure how to use the testcall tool to debug, but here we go with what I tried. The Main Thread message does never stop showing on the screen, I bet this is not the expected behavior tho. Maybe this can be of any help: asterisk-test:/usr/local/src/libunicall-0.0.3# cat testcall.conf destination-no 1150901010 protocol-class mfcr2 protocol-variant br,10,4 protocol-end cpe on-offered accept circuits 1-10 asterisk-test:/usr/local/src/libunicall-0.0.3# ./testcall Chan 1, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901010' Chan 2, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901011' Chan 3, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901012' Chan 4, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901013' Chan 5, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901014' Chan 6, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901015' Chan 7, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901016' Chan 8, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901017' Chan 9, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901018' Chan 10, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901019' Loading protocol mfcr2 Thread for channel 0 Thread for channel 1 Thread for channel 2 Thread for channel 3 Thread for channel 4 Thread for channel 5 Thread for channel 6 Thread for channel 7 Thread for channel 8 Thread for channel 9 Chan 1: -- Local end unblocked! :-) Chan 1: -- Local end unblocked! :-) Chan 2: -- Local end unblocked! :-) Chan 2: -- Local end unblocked! :-) Chan 3: -- Local end unblocked! :-) Chan 3: -- Local end unblocked! :-) Chan 4: -- Local end unblocked! :-) Chan 4: -- Local end unblocked! :-) Chan 5: -- Local end unblocked! :-) Chan 5: -- Local end unblocked! :-) Chan 6: -- Local end unblocked! :-) Chan 6: -- Local end unblocked! :-) Chan 7: -- Local end unblocked! :-) Chan 7: -- Local end unblocked! :-) Chan 8: -- Local end unblocked! :-) Chan 8: -- Local end unblocked! :-) Chan 9: -- Local end unblocked! :-) Chan 9: -- Local end unblocked! :-) Chan 10: -- Local end unblocked! :-) Chan 10: -- Local end unblocked! :-) Chan 1: -- Far end unblocked! :-) Chan 1: -- Far end unblocked! :-) Chan 1: Initiating call Chan 1: -- Dialing on channel 0 Chan 1: -- Dialing on channel 0 Chan 2: -- Far end unblocked! :-) Chan 2: -- Far end unblocked! :-) Chan 2: Initiating call Chan 2: -- Dialing on channel 0 Chan 2: -- Dialing on channel 0 Chan 3: -- Far end unblocked! :-) Chan 3: -- Far end unblocked! :-) Chan 3: Initiating call Chan 3: -- Dialing on channel 0 Chan 3: -- Dialing on channel 0 Chan 4: -- Far end unblocked! :-) Chan 4: -- Far end unblocked! :-) Chan 4: Initiating call Chan 4: -- Dialing on channel 0 Chan 4: -- Dialing on channel 0 Chan 5: -- Far end unblocked! :-) Chan 5: -- Far end unblocked! :-) Chan 5: Initiating call Chan 5: -- Dialing on channel 0 Chan 5: -- Dialing on channel 0 Chan 6: -- Far end unblocked! :-) Chan 6: -- Far end unblocked! :-) Chan 6: Initiating call Chan 6: -- Dialing on channel 0 Chan 6: -- Dialing on channel 0 Chan 7: -- Far end unblocked! :-) Chan 7: -- Far end unblocked! :-) Chan 7: Initiating call Chan 7: -- Dialing on channel 0 Chan 7: -- Dialing on channel 0 Chan 8: -- Far end unblocked! :-) Chan 8: -- Far end unblocked! :-) Chan 8: Initiating call Chan 8: -- Dialing on channel 0 Chan 8: -- Dialing on channel 0 Chan 9: -- Far end unblocked! :-) Chan 9: -- Far end unblocked! :-) Chan 9: Initiating call Chan 9: -- Dialing on channel 0 Chan 9: -- Dialing on channel 0 Chan 10: -- Far end unblocked! :-) Chan 10: -- Far end unblocked! :-) Chan 10: Initiating call Chan 10: -- Dialing on channel 0 Chan 10: -- Dialing on channel 0 Chan 3: -- Alerting on channel 0 Chan 3: -- Alerting on channel 0 Chan 8: -- Alerting on channel 0 Chan 8: -- Alerting on channel 0 Chan 1: -- Alerting on channel 0 Chan 1: -- Alerting on channel 0 Chan 4: -- Alerting on channel 0 Chan 4: -- Alerting on channel 0 Chan 2: -- Alerting on channel 0 Chan 2: -- Alerting on channel 0 Chan 6: -- Alerting on channel 0 Chan 6: -- Alerting on channel 0 Chan 7: -- Alerting on channel 0 Chan 7: -- Alerting on channel 0 Chan 9: -- Alerting on channel 0 Chan 9: -- Alerting on channel 0 Chan 5: -- Alerting on channel 0 Chan 5: -- Alerting on channel 0 Chan 10: -- Alerting on channel 0 Chan 10: -- Alerting on channel 0 Main thread Main thread Main thread Main thread Main thread Main thread Main thread Main thread Chan 6: -- Protocol failure on channel 0, cause (32773) Unexpected CAS bit pattern Chan 6:
Re: [Asterisk-Users] Unicall acting really funny
Joao. The more important thing about testcall is that it allows you to isolate the problem (you dont need asterisk) . I would recommend you to read this document I wrote: http://phpmexic.u33.0web-hosting.com/wordpress/misc/mfcr2-asterisk-unicall.pdf Here is described a bit more detailed. Is in spanishg, but since im able to read portuguese I think may be you can understand it. The more important thing is to increment testcall logging verbosity. For that you need to edit testcall.c, there you will find a function named run_uc(), search the logging_level variable and let it be UC_LOG_SEVERITY_MASK, then make testcall and run the test again but use only in 1 circuit. That will show in wich part of the initial signaling is staying stuck. Other more clear test is modify mfcr2.c, in the first line it has commented a #define AUDIO_LOG, uncomment it and libmfcr2 will save all the audio signalingin in a couple of files in the same folder you execute testcall. ONce done that, you can send me the audio files and the logging messages and may be I will be able to know what the problem is. Regards On 6/13/06, Joao Mesquita [EMAIL PROTECTED] wrote: Dear Moises, Thank you for your reply! I am not sure how to use the testcall tool to debug, but here we go with what I tried. The Main Thread message does never stop showing on the screen, I bet this is not the expected behavior tho. Maybe this can be of any help: asterisk-test:/usr/local/src/libunicall-0.0.3# cat testcall.conf destination-no 1150901010 protocol-class mfcr2 protocol-variant br,10,4 protocol-end cpe on-offered accept circuits 1-10 asterisk-test:/usr/local/src/libunicall-0.0.3# ./testcall Chan 1, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901010' Chan 2, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901011' Chan 3, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901012' Chan 4, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901013' Chan 5, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901014' Chan 6, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901015' Chan 7, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901016' Chan 8, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901017' Chan 9, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901018' Chan 10, class 'mfcr2', variant 'br,10,4', end 1, caller 1461727523, from '' to '1150901019' Loading protocol mfcr2 Thread for channel 0 Thread for channel 1 Thread for channel 2 Thread for channel 3 Thread for channel 4 Thread for channel 5 Thread for channel 6 Thread for channel 7 Thread for channel 8 Thread for channel 9 Chan 1: -- Local end unblocked! :-) Chan 1: -- Local end unblocked! :-) Chan 2: -- Local end unblocked! :-) Chan 2: -- Local end unblocked! :-) Chan 3: -- Local end unblocked! :-) Chan 3: -- Local end unblocked! :-) Chan 4: -- Local end unblocked! :-) Chan 4: -- Local end unblocked! :-) Chan 5: -- Local end unblocked! :-) Chan 5: -- Local end unblocked! :-) Chan 6: -- Local end unblocked! :-) Chan 6: -- Local end unblocked! :-) Chan 7: -- Local end unblocked! :-) Chan 7: -- Local end unblocked! :-) Chan 8: -- Local end unblocked! :-) Chan 8: -- Local end unblocked! :-) Chan 9: -- Local end unblocked! :-) Chan 9: -- Local end unblocked! :-) Chan 10: -- Local end unblocked! :-) Chan 10: -- Local end unblocked! :-) Chan 1: -- Far end unblocked! :-) Chan 1: -- Far end unblocked! :-) Chan 1: Initiating call Chan 1: -- Dialing on channel 0 Chan 1: -- Dialing on channel 0 Chan 2: -- Far end unblocked! :-) Chan 2: -- Far end unblocked! :-) Chan 2: Initiating call Chan 2: -- Dialing on channel 0 Chan 2: -- Dialing on channel 0 Chan 3: -- Far end unblocked! :-) Chan 3: -- Far end unblocked! :-) Chan 3: Initiating call Chan 3: -- Dialing on channel 0 Chan 3: -- Dialing on channel 0 Chan 4: -- Far end unblocked! :-) Chan 4: -- Far end unblocked! :-) Chan 4: Initiating call Chan 4: -- Dialing on channel 0 Chan 4: -- Dialing on channel 0 Chan 5: -- Far end unblocked! :-) Chan 5: -- Far end unblocked! :-) Chan 5: Initiating call Chan 5: -- Dialing on channel 0 Chan 5: -- Dialing on channel 0 Chan 6: -- Far end unblocked! :-) Chan 6: -- Far end unblocked! :-) Chan 6: Initiating call Chan 6: -- Dialing on channel 0 Chan 6: -- Dialing on channel 0 Chan 7: -- Far end unblocked! :-) Chan 7: -- Far end unblocked! :-) Chan 7: Initiating call Chan 7: -- Dialing on channel 0 Chan 7: -- Dialing on channel 0 Chan 8: -- Far end unblocked! :-) Chan 8: -- Far end unblocked! :-) Chan 8: Initiating call Chan 8: -- Dialing on channel 0 Chan 8: -- Dialing on channel 0 Chan 9: -- Far end unblocked! :-) Chan 9: -- Far end unblocked! :-) Chan 9:
Re: [Asterisk-Users] Unicall acting really funny
I helped debugging a tormenta card about 1 month ago. Thats the only experience I have with Tormenta card. But he had the same message about FAS error in /proc/zaptel. Why dont you try using testcall (included with libunicall), that will tell you exactly where the call is staying? On 6/10/06, Joao Mesquita [EMAIL PROTECTED] wrote: Hello guys! I hope you bare with yet another newbie on the list! :-) I am trying to setup an asterisk installation in between a Siemens HiPath 3800 and my local carrier (Telefonica/Brazil). Both running R2. ISDN is not an option on the carrier. :-( I could apparently setup both E1s just fine according to zttool (both OK with no alarms) but, and this is where it starts to get funky, some calls from some phones get trough and some don't. Besides that, when I put the loglevel parameter in unicall.conf, asterisk gives me a seg fault when loading the module. The last problem is that when I try the reload command on the asterisk CLI, the E1s get blocked again because chan_unicall.so fails to reload. First of all, lets start with my environment: Linux version: 2.4.27-2-386 #1 Wed Aug 17 09:33:35 UTC 2005 i686 GNU/Linux Asterisk version: 1.2.9.1 Zaptel version: 1.2.6 Unicall: unicall-0.0.3pre9 Board: ATCOM AX-4E (same as Tormenta2) asterisk-test:/# cat /proc/interrupts CPU0 0: 277514IO-APIC-edge timer 1: 2IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 4IO-APIC-edge rtc 14: 38259IO-APIC-edge ide0 15: 12IO-APIC-edge ide1 16: 0 IO-APIC-level usb-uhci, usb-uhci 17: 0 IO-APIC-level Intel ICH5 18: 0 IO-APIC-level usb-uhci 19: 0 IO-APIC-level usb-uhci 22:2700297 IO-APIC-level tor2 23: 14842 IO-APIC-level ehci_hcd, eth0 NMI: 0 LOC: 277453 ERR: 0 MIS: 0 # E1 connected to the carrier ### asterisk-test:/# cat /proc/zaptel/1 Span 1: Tor2/0/1 Tormenta 2 (PCI) Quad E1 Card 0 Span 1 HDB3/ ClockSource BPV count: 812 FAS error count: 3 1 Tor2/0/1/1 CAS (In use) 2 Tor2/0/1/2 CAS (In use) 3 Tor2/0/1/3 CAS (In use) (snip) 27 Tor2/0/1/27 CAS (In use) 28 Tor2/0/1/28 CAS (In use) 29 Tor2/0/1/29 CAS (In use) 30 Tor2/0/1/30 CAS (In use) 31 Tor2/0/1/31 CAS (In use) # E1 connected to the HiPath # Span 2: Tor2/0/2 Tormenta 2 (PCI) Quad E1 Card 0 Span 2 HDB3/ BPV count: 329 FAS error count: 6 32 Tor2/0/2/1 CAS (In use) 33 Tor2/0/2/2 CAS (In use) 34 Tor2/0/2/3 CAS (In use) 35 Tor2/0/2/4 CAS (In use) (snip) 57 Tor2/0/2/26 CAS (In use) 58 Tor2/0/2/27 CAS (In use) 59 Tor2/0/2/28 CAS (In use) 60 Tor2/0/2/29 CAS (In use) 61 Tor2/0/2/30 CAS (In use) 62 Tor2/0/2/31 CAS (In use) asterisk-test:/etc# cat zaptel.conf span=1,1,0,cas,hdb3 span=2,0,0,cas,hdb3 span=3,0,0,cas,hdb3 span=4,0,0,cas,hdb3 # cas=1-15:1101 cas=17-31:1101 # cas=32-46:1101 cas=48-62:1101 # cas=63-77:1101 cas=79-93:1101 # cas=94-108:1101 cas=110-124:1101 asterisk-test:/etc/asterisk# cat unicall.conf [channels] language=br protocolclass=mfcr2 context=from-e1-externo protocolvariant=br,20,20 protocolend=cpe group=1 channel = 1-15 channel = 17-31 language=br context=from-e1-interno group=2 channel = 32-46 channel = 48-62 Ok, now let's go with the logs! :-) When asterisk starts everything goes OK without the loglevel entry in unicall.conf, but with it we get: [chan_unicall.so] = (Unified call processing (UniCall)) == Parsing '/etc/asterisk/unicall.conf': Found Segmentation fault (core dumped) asterisk-test:~# Ouch ... error while writing audio data: : Broken pipe Warning, flexibel rate not heavily tested! Now dialing from a DECT (Siemens Gigaset C50) extension behind Hipath to SIP/teste: Jun 10 02:24:36 WARNING[1652]: chan_unicall.c:2694 handle_uc_event: Unicall/39 event Detected Jun 10 02:24:42 WARNING[1652]: chan_unicall.c:2694 handle_uc_event: Unicall/39 event Offered Jun 10 02:24:42 WARNING[1652]: chan_unicall.c:2805 handle_uc_event: CRN 32770 - Offered on channel 0 (ANI: 1021, DNIS: 8080, Cat: 0) Jun 10 02:24:42 WARNING[1652]: chan_unicall.c:2694 handle_uc_event: Unicall/39 event Accepted -- Executing Answer(UniCall/39-1, ) in new stack Jun 10 02:24:42 WARNING[1769]: chan_unicall.c:1460 unicall_answer: Answer Call -- Executing Dial(UniCall/39-1, SIP/teste) in new stack -- Called teste -- SIP/teste-291f is ringing Jun 10 02:24:43 WARNING[1769]: chan_unicall.c:2490 unicall_indicate: unicall_indicate 3 -- SIP/teste-291f answered UniCall/39-1 Jun 10 02:24:47 WARNING[1769]: chan_unicall.c:2490 unicall_indicate: unicall_indicate -1 == Spawn extension (from-e1-interno, 8080, 2) exited non-zero on 'UniCall/39-1' -- Hungup
Re: [Asterisk-Users] Unicall acting really funny
Hi Joao, One of the *big* advantages of the Tormenta 2 cards over the more recent cards from Digium is the driver actually counts various errors, and lets you see link problems easily. The FAS error count is increasing, which means you have a link problem. There, that was easy. With a TE411 it would take ages to figure that one out. Now, what exactly is your link problem? The first thing I would try is to change the CRC4 selection for your card. Having that wrong produces some interesting results. Steve Joao Mesquita wrote: Hello guys! I hope you bare with yet another newbie on the list! :-) I am trying to setup an asterisk installation in between a Siemens HiPath 3800 and my local carrier (Telefonica/Brazil). Both running R2. ISDN is not an option on the carrier. :-( I could apparently setup both E1s just fine according to zttool (both OK with no alarms) but, and this is where it starts to get funky, some calls from some phones get trough and some don't. Besides that, when I put the loglevel parameter in unicall.conf, asterisk gives me a seg fault when loading the module. The last problem is that when I try the reload command on the asterisk CLI, the E1s get blocked again because chan_unicall.so fails to reload. First of all, lets start with my environment: Linux version: 2.4.27-2-386 #1 Wed Aug 17 09:33:35 UTC 2005 i686 GNU/Linux Asterisk version: 1.2.9.1 Zaptel version: 1.2.6 Unicall: unicall-0.0.3pre9 Board: ATCOM AX-4E (same as Tormenta2) asterisk-test:/# cat /proc/interrupts CPU0 0: 277514IO-APIC-edge timer 1: 2IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 4IO-APIC-edge rtc 14: 38259IO-APIC-edge ide0 15: 12IO-APIC-edge ide1 16: 0 IO-APIC-level usb-uhci, usb-uhci 17: 0 IO-APIC-level Intel ICH5 18: 0 IO-APIC-level usb-uhci 19: 0 IO-APIC-level usb-uhci 22:2700297 IO-APIC-level tor2 23: 14842 IO-APIC-level ehci_hcd, eth0 NMI: 0 LOC: 277453 ERR: 0 MIS: 0 # E1 connected to the carrier ### asterisk-test:/# cat /proc/zaptel/1 Span 1: Tor2/0/1 Tormenta 2 (PCI) Quad E1 Card 0 Span 1 HDB3/ ClockSource BPV count: 812 FAS error count: 3 1 Tor2/0/1/1 CAS (In use) 2 Tor2/0/1/2 CAS (In use) 3 Tor2/0/1/3 CAS (In use) (snip) 27 Tor2/0/1/27 CAS (In use) 28 Tor2/0/1/28 CAS (In use) 29 Tor2/0/1/29 CAS (In use) 30 Tor2/0/1/30 CAS (In use) 31 Tor2/0/1/31 CAS (In use) # E1 connected to the HiPath # Span 2: Tor2/0/2 Tormenta 2 (PCI) Quad E1 Card 0 Span 2 HDB3/ BPV count: 329 FAS error count: 6 32 Tor2/0/2/1 CAS (In use) 33 Tor2/0/2/2 CAS (In use) 34 Tor2/0/2/3 CAS (In use) 35 Tor2/0/2/4 CAS (In use) (snip) 57 Tor2/0/2/26 CAS (In use) 58 Tor2/0/2/27 CAS (In use) 59 Tor2/0/2/28 CAS (In use) 60 Tor2/0/2/29 CAS (In use) 61 Tor2/0/2/30 CAS (In use) 62 Tor2/0/2/31 CAS (In use) asterisk-test:/etc# cat zaptel.conf span=1,1,0,cas,hdb3 span=2,0,0,cas,hdb3 span=3,0,0,cas,hdb3 span=4,0,0,cas,hdb3 # cas=1-15:1101 cas=17-31:1101 # cas=32-46:1101 cas=48-62:1101 # cas=63-77:1101 cas=79-93:1101 # cas=94-108:1101 cas=110-124:1101 asterisk-test:/etc/asterisk# cat unicall.conf [channels] language=br protocolclass=mfcr2 context=from-e1-externo protocolvariant=br,20,20 protocolend=cpe group=1 channel = 1-15 channel = 17-31 language=br context=from-e1-interno group=2 channel = 32-46 channel = 48-62 Ok, now let's go with the logs! :-) When asterisk starts everything goes OK without the loglevel entry in unicall.conf, but with it we get: [chan_unicall.so] = (Unified call processing (UniCall)) == Parsing '/etc/asterisk/unicall.conf': Found Segmentation fault (core dumped) asterisk-test:~# Ouch ... error while writing audio data: : Broken pipe Warning, flexibel rate not heavily tested! Now dialing from a DECT (Siemens Gigaset C50) extension behind Hipath to SIP/teste: Jun 10 02:24:36 WARNING[1652]: chan_unicall.c:2694 handle_uc_event: Unicall/39 event Detected Jun 10 02:24:42 WARNING[1652]: chan_unicall.c:2694 handle_uc_event: Unicall/39 event Offered Jun 10 02:24:42 WARNING[1652]: chan_unicall.c:2805 handle_uc_event: CRN 32770 - Offered on channel 0 (ANI: 1021, DNIS: 8080, Cat: 0) Jun 10 02:24:42 WARNING[1652]: chan_unicall.c:2694 handle_uc_event: Unicall/39 event Accepted -- Executing Answer(UniCall/39-1, ) in new stack Jun 10 02:24:42 WARNING[1769]: chan_unicall.c:1460 unicall_answer: Answer Call -- Executing Dial(UniCall/39-1, SIP/teste) in new stack -- Called teste -- SIP/teste-291f is ringing Jun 10 02:24:43 WARNING[1769]: chan_unicall.c:2490 unicall_indicate: unicall_indicate 3 -- SIP/teste-291f answered UniCall/39-1 Jun 10
