[asterisk-r2] Too many network congestions. Requested file.

[Moises Silva]

Thanks,

I checked the log, and I don't think it's a problem with the tone
detection, the small delay in their response may be because they're
trying to route to number before sending us a response (like accepting
the call when the user is available, or sending network congestion
when there is no trunks available, or sending user busy etc), so I
think the dealy is pretty normal, most likely if you check successful
calls you will find the "accept call" tone is also a bit delayed if
you compare it with the other responses.

Having said that, the destiny number is exactly 1563332536 ?

Have you noticed if the network congestion happens always to the same numbers?

On Mon, Jun 8, 2009 at 8:30 PM, Daniel A.
Veiga<dveiga at advtechnology.com.ar> wrote:
> The log file a sent as an attachment con be found at:
>
> http://pastebin.com/m775471f3
>
> Thanks,
>
>
>                               Ing. Daniel A. Veiga
>                                ADV Technology SRL
>
>
>
>
>> On Fri, Jun 5, 2009 at 11:06 PM, Daniel A.
>> Veiga<dveiga at advtechnology.com.ar> wrote:
>>> Â  Â Looking into the problem I found that I received a "network
>>> congestion" when the other end detected we stopped sending DNIS for
>>> more than about 200ms. My end never stopped sending, the problem is
>>> the other end is not detecting them for some reason.
>>
>> How do you know the other end does not detect the tone? I read your
>> past e-mail:
>> http://lists.digium.com/pipermail/asterisk-r2/2009-June/000915.html,
>> however, you should avoid attaching files, instead use pastebin, I
>> cannot see the trace because I deleted your e-mail since I was busy at
>> that moment. However if you had used pastebin I could access to it
>> now.
>>
>> Just from reading your past e-mail without seeing the traces now, I
>> can tell you I don't think the other end is shutting down the call
>> with network congestion just because in 300ms they were not able to
>> detect the tone, sounds like a very small time frame for detection,
>> that kind of timeouts are typically in the order of several seconds,
>> not milliseconds. Anyways, please pastebin the call trace if you want
>> me to take a look at it.
>>
>>>
>>> Â  Â I have no CRC errors, so I must believe the problem is not at
>>> the
>>> interface layer, then it must be logical (data carried by the
>>> interface level). I then looked at r2engine.c and found something
>>> strange: When transmitting DTMF then higher tone is always
>>> transmitted louder than the lower one. This is called twist and is
>>> inherited from analog line's frequency response. But the twist,
>>> which is implemented in openr2 library, is not used. The constant
>>> DTMF_NORMAL_TWIST is defined, but when openr2_dtmf_tx_set_level()
>>> is called it is not used. In fact a 0 is passed as the twist
>>> parameter.
>> The tones that are sent during call setup are *NOT* DTMF tones in your
>> case. The DTMF tones you see that are sent in openr2 library are some
>> experimental code for DTMF-R2 variant used in Venezuela, but Argentina
>> variant and all other variants use MF tones, that is, openr2_mf_tx()
>> etc. So this twist has nothing to do with your issue.
>>
>> --
>> Moises Silva
>> Software Developer
>> Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON
>> L3R 9T3 Canada
>> t. 1 905 474 1990 x 128 | e. moy at sangoma.com
>>
>
>
>
> _______________________________________________
> --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
>



-- 
Moises Silva
Software Developer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON
L3R 9T3 Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com