Posted: Fri Apr 11, 2008 2:13 pm Post subject: [Asterisk-video] Video stream delayed (SIP->3G)
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--
Posted: Sat Apr 12, 2008 11:41 am Post subject: [Asterisk-video] Video stream delayed (SIP->3G)
A new test again :
Remark : I have a media configuration with a video bandwidth limiter
set to 20000bps
3G handset ----> Asterisk (call SIP) ----> SIP(video)
I have the same problem.
The stream delayed is always the SIP -> 3G video stream.
So I think the delay is in the H324m stack and/or in the Asterisk scheduling methods.
In the SIP -> 3G -> 3Gecho, I have followed an incoming H263 RTP packet. The h263 datas (~1k bytes ethernet) are sliced in 7 RTP packets (200 bytes ethernet, in this case : echo 3G test). Each packets is send with a delay (20ms).
In the case echo3G, the packet are transfered to the destination. So I can say that 1 RTP packet have taken ~7x20ms = ~140ms to be transfered.
All the packets are delayed so, after some seconds, the stream delay is important. After some minutes, the delay is very very very important.
A other case with playmp4 application. In the 3GP hinted file, there are a lot of h263 RTP packets with a size of 1k bytes too. But in this case I don't have any delay.
What do you think about ?
I am analyzing the two source codes...
Sergio, have you an idea ?
Regards,
Tech from i6net
Borja SIXTO a écrit :
Quote:
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--
Posted: Sat Apr 12, 2008 3:24 pm Post subject: [Asterisk-video] Video stream delayed (SIP->3G)
The most probably reason for video delay is because you send video with too much bandwith.
Audio is priorized in the h32m4 library so it's played continiously so video is been queued in the
library so the delay keeps increasing.
Use app_transcoder or fix your video bandwith limiter and try again ;)
Best regards
Sergio
Borja SIXTO escribió:
Quote:
Quote:
A new test again :
Remark : I have a media configuration with a video bandwidth limiter
set to 20000bps
3G handset ----> Asterisk (call SIP) ----> SIP(video)
I have the same problem.
The stream delayed is always the SIP -> 3G video stream.
So I think the delay is in the H324m stack and/or in the Asterisk scheduling methods.
In the SIP -> 3G -> 3Gecho, I have followed an incoming H263 RTP packet. The h263 datas (~1k bytes ethernet) are sliced in 7 RTP packets (200 bytes ethernet, in this case : echo 3G test). Each packets is send with a delay (20ms).
In the case echo3G, the packet are transfered to the destination. So I can say that 1 RTP packet have taken ~7x20ms = ~140ms to be transfered.
All the packets are delayed so, after some seconds, the stream delay is important. After some minutes, the delay is very very very important.
A other case with playmp4 application. In the 3GP hinted file, there are a lot of h263 RTP packets with a size of 1k bytes too. But in this case I don't have any delay.
What do you think about ?
I am analyzing the two source codes...
Sergio, have you an idea ?
Regards,
Tech from i6net
Borja SIXTO a écrit :
Quote:
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--
Posted: Sat Apr 12, 2008 4:39 pm Post subject: [Asterisk-video] Video stream delayed (SIP->3G)
Hi Sergio,
I will check your explanation...
I use Kapanga SIP phone, and I confirm that I have set the banwidth to
20kbps.
I will check the real bndwidth, thanks.
Two questions :
1/
I have made a binaries package of the fontventa asterisk applications.
Can I publish it in this mailing list ?
I think it could help some users to install the fontventa modules.
2/
I would like to publish some Spanish 3G phones connected to your
applications in order to have use cases.
Can I publish its too ?
Thanks, Saludos,
Tech from i6net
Sergio Garcia Murillo a écrit :
Quote:
The most probably reason for video delay is because you send video
with too much bandwith.
Audio is priorized in the h32m4 library so it's played continiously so
video is been queued in the
library so the delay keeps increasing.
Use app_transcoder or fix your video bandwith limiter and try again ;)
Best regards
Sergio
Borja SIXTO escribió:
> A new test again :
>
> Remark : I have a media configuration with a video bandwidth limiter
> set to 20000bps
>
> 3G handset ----> Asterisk (call SIP) ----> SIP(video)
> I have the same problem.
> The stream delayed is always the SIP -> 3G video stream.
>
> So I think the delay is in the H324m stack and/or in the Asterisk scheduling methods.
>
> In the SIP -> 3G -> 3Gecho, I have followed an incoming H263 RTP packet. The h263 datas (~1k bytes ethernet) are sliced in 7 RTP packets (200 bytes ethernet, in this case : echo 3G test). Each packets is send with a delay (20ms).
> In the case echo3G, the packet are transfered to the destination. So I can say that 1 RTP packet have taken ~7x20ms = ~140ms to be transfered.
> All the packets are delayed so, after some seconds, the stream delay is important. After some minutes, the delay is very very very important.
>
> A other case with playmp4 application. In the 3GP hinted file, there are a lot of h263 RTP packets with a size of 1k bytes too. But in this case I don't have any delay.
>
>
> What do you think about ?
>
>
> I am analyzing the two source codes...
> Sergio, have you an idea ?
>
> Regards,
>
>
> Tech from i6net
>
>
> Borja SIXTO a écrit :
>
>> 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
>
Posted: Mon Apr 14, 2008 6:55 am Post subject: [Asterisk-video] Video stream delayed (SIP->3G)
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:
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--
Posted: Mon Apr 14, 2008 2:35 pm Post subject: [Asterisk-video] Video stream delayed (SIP->3G)
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 :
Quote:
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:
> 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--
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum