[Asterisk-video] Instable h324m outbound calls

[Klaus Darilion]

Thanks for the feedback!

Thomas Frieling wrote:
> Hi all!
> 
> Jose was right, our provider is the problem (as so often)...
> We just solved the problem by moving from Versatel to BritishTelecom. 
> Now everything works fine.
> 
> Thanks for your help,
> Thomas
> 
> 
> Jose M. Recio schrieb:
>> I suffered similar problems with one of my ISDN lines.
>> The root cause in my cause was related with the insertion of voice-echo
>> cancellers in some routes. Those cancellers break channel transparency for
>> data.
>> In my case, incoming calls worked fine because the interconnection between
>> mobile-fixed network always used routes without cancellers. Outgoing calls
>> that progressed with canceller-free routes went fine, but when the route had
>> a canceller, call failed, with the same symptom you are seeing.
>> Check with your provider.
>>
>>
>> -----Mensaje original-----
>> De: asterisk-video-bounces at lists.digium.com
>> [mailto:asterisk-video-bounces at lists.digium.com] En nombre de Klaus Darilion
>> Enviado el: jueves, 10 de abril de 2008 9:38
>> Para: Development discussion of video media support in Asterisk
>> Asunto: Re: [Asterisk-video] Instable h324m outbound calls
>>
>>
>>
>> Sven Brandau schrieb:
>>   
>>> Hi Experts!
>>>
>>> After playing some hours with outgoing calls only 50% of the calls are 
>>> successful. The connection with the phone is established, but the call 
>>> will be aborted after ~ 15 sec without any audio or video (Motorola 
>>> K3). Sometimes the phone is hanging in an endless loop, no video, no
>>>     
>> audio, but the call will not aborted (Nokia N73).
>>   
>>> I've traced the incoming h.223 packets and found some errors. E.g.: 
>>> (from h245_in.log)
>>>
>>>
>>> E1 4D 00 00 00 E1 4D 00 00 00 E1 4D 00 00 00 E1 4D 00 00 00 E1 4D 00 00 00
>>>     
>> E1 4D 00 00 00 E1 4D
>>   
>>>             flg            flg            flg            flg
>>>     
>> flg            flg
>>   
>>> 00 00 00 E1 4D 00 00 00 E1 4D 00 77 4D AB 80 C0 F7 0D AB 60 00 87 8D AB 18
>>>     
>> 20 A7 2D AB 48 18 7F
>>   
>>>                      flg       ^^^^^^^^^^^^^^^^^
>>> D1 AB 68 38 0F 91 AB 96 08 F3 41 AB 26 A8 CB A1 AB 8E B6 3B 99 AB E9 
>>> 12 AA F2 5F 22 A8 73 C3 AB
>>>
>>>
>>> The byte sequence from 00 77 4D onwards seems to be corrupt.
>>>
>>> Is anyone here who can explain that? Is this the normal thing of
>>>     
>> corrupting data over the air?
>>
>> Corrupted data may happen. But it should also happen for incoming 3G calls.
>>
>>   
>>> But the protocol should be able to work over error prone channels.
>>>     
>> It should. But of course it depends on the implementation in libh324m.
>>
>>   
>>> In case of incoming calls everything works fine.
>>>     
>>
>> That's the strange part :-(
>>
>> klaus
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-video
>>   
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-video