[Asterisk-video] Video stream delayed (SIP->3G)

Borja SIXTO borja.sixto at i6net.com
Mon Apr 14 10:24:47 CDT 2008


Hi Klaus and Sergio,

That is right, the Soft Phone Kapanga generate a bandwidth greater that 
80kbps...
The Bandwidth limiter is not efficient.

For information :
- with x-lite, it works well but the video sending is not easy to 
activate (you must push the button send video, and generaly I shoud 
close and open the left tab).
- with kapanga, I have bandwidth problems (sometimes it works, I am 
going to contact the Kapanga support).
- with intellivic, I am making tests, but I think the payload 
h263/rfc2429 enabled generate h263+ video stream and the 3G phones don't 
show the video.

I am using the app_transcoder but I have some problems...
I will post a specific message for that.

Regards and thanks,


Tech from i6net


Klaus Darilion a écrit :
> The video bandwidth is too high. I do not know kapanga, but e.g. with 
> eyebeam you have to set bandwidth to "Cable, DSL" or send to eyebeam an 
> SDP with bandwidth settings using this patch:
>
> http://bugs.digium.com/view.php?id=12134
>
> regards
> klaus
>
> Borja SIXTO schrieb:
>   
>> Hi alls,
>>
>> I am making test with the SIP -> 3G calls.
>> I have a delay generated by the Asterisk/h324m stack.
>>
>> Here my test scenarios description :
>>
>> 3G handset ----> Asterisk (3G echo)
>> All is OK.
>>
>> SIP(video) ----> Asterisk (video echo)
>> All is OK.
>>
>> 3G handset ----> Asterisk (call 3G) ----> Asterisk (3G echo)
>> All is OK.
>>
>> SIP(video) ----> Asterisk (call 3G) ----> 3G handset
>> The Audio is OK for the two streams.
>> The Video from 3G to SIP ok o too.
>> The Video form SIP to 3G have a very important delay (> some minutes 
>> !!!). If the call is long, the delay increase. But the full video 
>> sequence is complete (It is probably strored in the h324m stack).
>>
>> SIP(video) ----> Asterisk (call 3G) ----> Asterisk (3G echo)
>> The Audio is OK for the two streams.
>> The Video echo have the important delay (> some minutes !!!). Same 
>> result as the previous case.
>>
>> I am analysing the WireShark capture (Video RTP packets).
>> I will post the results...
>>
>> Any body have the same problem ?
>> Have you an idea ?
>>
>> Thanks,
>>
>>
>> Tech from i6net
>>
>>
>> _______________________________________________
>> --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
>   




More information about the asterisk-video mailing list