[asterisk-r2] Not receiving incoming calls

Mariano Bianchi marianito.bianchi at gmail.com
Wed Jan 19 12:27:04 CST 2011


Thanks everyone for your answers. Continuing with this case, the telco says
that (after making the trace), the call is being rejected because of the
excessive amount of time that Asterisk is taking for the response. I need to
know how to minimize (less than 190ms) that time, in order the call not to
be rejected anymore.
Thank you very much for your help!
Here is the trace:

000 1001 H'46   BT27D-14434

35760 0000000                          R   0000 1001 H'46   BT27D-14434

20000 0044240 SEIZURE                  S   0000 1000 H'47   BT27D-14434

20190 0000190 SIG. FAULT               R   0000 1001 H'37   BT27D-14434

20520 0000330                          R   0000 1011 H'37   BT27D-14434

20540 0000020 SEIZURE ACKN.            R   0000 1011 H'32   BT27D-14434

20540 0000000 CLEAR FORWARD            S   0000 1001 H'32   BT27D-14434

20640 0000100                          R   0000 1011 H'33   BT27D-14434

21080 0000440                          R   0000 1001 H'33   BT27D-14434

21100 0000020 RELEASE GUARD            R   0000 1001 H'46   BT27D-14434

21100 0000000 IDLE                     S   0000 1001 H'46   BT27D-14434

35140 0014040 SEIZURE                  S   0000 1000 H'47   BT27D-14434

35340 0000200 SIG. FAULT               R   0000 1001 H'37   BT27D-14434

35680 0000340                          R   0000 1011 H'37   BT27D-14434

35700 0000020 SEIZURE ACKN.            R   0000 1011 H'32   BT27D-14434

35700 0000000 CLEAR FORWARD            S   0000 1001 H'32   BT27D-14434

35800 0000100                          R   0000 1011 H'33   BT27D-14434

36240 0000440                          R   0000 1001 H'33   BT27D-14434

36260 0000020 RELEASE GUARD            R   0000 1001 H'46   BT27D-14434

36260 0000000 IDLE                     S   0000 1001 H'46   BT27D-14434



 1 MINUTE



23500 0047240 SEIZURE                  S   0000 1000 H'47   BT27D-14434

23700 0000200 SIG. FAULT               R   0000 1001 H'37   BT27D-14434

24040 0000340                          R   0000 1011 H'37   BT27D-14434

24060 0000020 SEIZURE ACKN.            R   0000 1011 H'32   BT27D-14434

24060 0000000 CLEAR FORWARD            S   0000 1001 H'32   BT27D-14434

24160 0000100                          R   0000 1011 H'33   BT27D-14434

24600 0000440                          R   0000 1001 H'33   BT27D-14434

24620 0000020 RELEASE GUARD            R   0000 1001 H'46   BT27D-14434

24620 0000000 IDLE                     S   0000 1001 H'46   BT27D-14434



 Regards,
Mariano Bianchi.


On Sun, Jan 9, 2011 at 2:25 AM, Moises Silva <moises.silva at gmail.com> wrote:

> The problem is that the other end does not seem to like our seize ack
> signal and they hangup.
>
> You should call the telco and tell them why do they hangup the call.
>
> Moises Silva
> Senior Software Engineer
> Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R
> 9R6 Canada
> t. 1 905 474 1990 x128 | e. moy at sangoma.com
>
>
> On Thu, Jan 6, 2011 at 3:53 PM, Mariano Bianchi <
> marianito.bianchi at gmail.com> wrote:
>
>> Hi everyone:
>>                  Here are the details of my issue:
>> Elastix 2.0 server with Asterisk 1.6.2.15, libopenR2 1.3.0, dahdi 2.4.0.,
>> libpri 1.4.11.5.
>> I have a Xorcom Astribank 2 USB connected to the server. The E1 is up and
>> running (telmex E1 R2, in Mar del Plata, Argentina), and the outbound calls
>> are working OK.
>> The problem is with the incoming calls. They are not working. I receive
>> busy tone when dialing. Here are the logs:
>>
>> [Jan  6 17:45:58] DEBUG[5681] chan_dahdi.c: Chan 15 - Bits changed from
>> 0x08 to 0x00
>> [Jan  6 17:45:58] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Persistence
>> check is enabled, waiting 500 ms
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - Bits changed from
>> 0x08 to 0x00
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Persistence
>> check is enabled, waiting 500 ms
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - calling timer 3
>> (cas_persistence_check) callback
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS signal 0x00 has
>> persisted, handling ...
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Rx << [SEIZE]
>> 0x00
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - Initialized R2 MF
>> detector
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Tx >> [SEIZE
>> ACK] 0x0C
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Raw Tx >> 0x0D
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - Bits changed from
>> 0x00 to 0x08
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Persistence
>> check is enabled, waiting 500 ms
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - calling timer 3
>> (cas_persistence_check) callback
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS signal 0x00 has
>> persisted, handling ...
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Rx << [SEIZE]
>> 0x00
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - Initialized R2 MF
>> detector
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Tx >> [SEIZE
>> ACK] 0x0C
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Raw Tx >> 0x0D
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - Bits changed from
>> 0x00 to 0x08
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Persistence
>> check is enabled, waiting 500 ms
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - calling timer 4
>> (cas_persistence_check) callback
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS signal 0x08 has
>> persisted, handling ...
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Rx << [CLEAR
>> FORWARD] 0x08
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - Call ended
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Tx >> [IDLE]
>> 0x08
>> [Jan  6 17:45:59] DEBUG[5681] chan_dahdi.c: Chan 15 - CAS Raw Tx >> 0x09
>> [Jan  6 17:46:00] DEBUG[5681] chan_dahdi.c: Chan 17 - calling timer 4
>> (cas_persistence_check) callback
>> [Jan  6 17:46:00] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS signal 0x08 has
>> persisted, handling ...
>> [Jan  6 17:46:00] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Rx << [CLEAR
>> FORWARD] 0x08
>> [Jan  6 17:46:00] DEBUG[5681] chan_dahdi.c: Chan 17 - Call ended
>> [Jan  6 17:46:00] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Tx >> [IDLE]
>> 0x08
>> [Jan  6 17:46:00] DEBUG[5681] chan_dahdi.c: Chan 17 - CAS Raw Tx >> 0x09
>>
>> Do you know what could be happening?
>> Thanks,
>> Ing. Mariano Bianchi.
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-r2 mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20110119/4d79d0c8/attachment.htm>


More information about the asterisk-r2 mailing list