Hi,
We have had similar experiences when using mediastreamer2 to
call Tandberg phones using H264
The Tandberg phones send SPS/PPS frames very infrequently (something
like every 5th minute) and since we miss some RTP packets in the
beginning of the stream the video cannot be decoded. We solved this by requesting
a full picture update, using RFC5168 (XML Schema for Media Control); it is a
quite simple XML message conveyed through the SIP INFO method.
Best regards
Sven Westergren
nWise AB
From:
address@hidden
[mailto:address@hidden On
Behalf Of Abhishek Ranjan
Sent: den 10 juni 2010 09:57
To: Simon Morlat
Cc: address@hidden; address@hidden
Subject: Re: [Linphone-developers] problems in streaming on WAN for
linphone ported on TI DM365
Hi Simon,
After some more debugging and wireshark logs on both caller and receiver side
,we found out the following:
--we make the all using proxy
-- The reciever starts sending the packet as soon as it accepts the call
and it sends all the packet starting from RTP seq 0(from the wireshark logs on
receiver side)
-- The caller on receiving 200 OK sends the acknowledgement and starts
sending the packets.
-- But it receives the packet starting from RTP seq no 40-100. So it does not
receive all the packtes which the receiver has sent. it does not receive
packets from 0-40. which is causing our decoder somehow to fail as it does not
receive the Visual Object Sequence header
-- Looks like this is a problem of pin hole opening I mean until a packet is
sent out from a RTP port, it can't receive any packet from outside
-- As the caller starts sending the packets late after receiving the 200 Ok,
till that time RTP port on called side is not open so it misses some initial
packets sent by receiver.
-- I tried to confirm this by putting some sleep after sending 200 Ok from
receiver side, that is delay the sending of packets from receiver side.. so in
this case receiver side pinhole is not opened so it misses some initial packet
from caller side.. while caller recieves all the RTP packtes from the
beginning. So in this case video comes on the caller side..
How to make sure the ports are opened before any RTP packet is received,..Would
stun server help??
THanks,
Abhishek
On Wed, Jun 9, 2010 at 6:06 PM, Simon Morlat <address@hidden>
wrote:
Hi,
Maybe RTP packets are too big then discarded while going through the
internet ?
Simon
Le jeudi 03 juin 2010 à 21:51 +0530, Abhishek Ranjan a écrit :
> HI all,
>
>
> We are using linphone source for our SIP phone development on TI DM365
> SOC. I have written filters for video encoding and decoding which uses
> TI's hardware encoder and decoder chip for video enc/dec operation and
> the rtp stack I am using as is. The audio part is same as present in
> linphone wiht G711 codec.
>
>
> For video My graph is very simple:
>
>
> cap_enc filter------> rtpsend
> rtprecv----------------->decode_display filter
>
>
> where cap_enc and decode_display filters are developed by us.
> We have successfully tested the sytem in LAN (Local Area
> Network)conditions where there is no limit on upload/download
> speed.and we have absolutely no problems in LAN testing conditions.
> But we are facing issues while making calls on WAN via proxy. We are
> getting video in only one direction. But nothing in other direction.
> The issue we are facing is linphone is not able to send RTP packets on
> other side.
> -- Our test set up consist of one unit connected to 1 Mbps broadband
> and the other one to a 2 Mbps leased line connection.
> -- The video resolution we are using is 4-CIF
> -- tried to experiment with jitt_compensation but nothing happened
> other than increase in delay
> -- Also tried to increase the video compression by relaxing the
> quantization parameter..
> -- The video decode and display is successful on the unit which
> receives the call and this is consistent all the time. We dont get any
> successful decoding and display on the unit making the call.
> -- RTP statistics showing that no of rtp packtes successfully
> delivered to the application is very low compared to the total number
> of packets received.
>
>
>
>
> Any suggestion on what could possibly go wrong while switching from
> LAN to WAN.
>
>
> Thanks,
> Abhishek Ranjan
>
>
>
_______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers