Dmitry- Klaus makes a good point as usual. I think his calculation is based on 20 msec packet time. One thing you might try is setting G729 packet time to 40 msec; i.e. four (4) G729 packets in each RTP payload. In this case overall bitrate (including overhead) would be 16 kbps. But you could see increased overall latency which may cause other problems. I think there is a "ptime" parameter in pjsip that controls this. Possibly something to try. -Jeff Klaus Darilion wrote: > > Hi Dmitry! > > Dmitry SJ wrote: > > Hello, > > > > In general, the main problem with mobile networking is that you have a > > rather wide Inbound channel and very narrow Outbound channel. Thus, if > > at least one entity has wide narrowband (3G, WiFi connected), the other > > side have clean incoming audio. The tests of the mobile network are the > > following: > > 1st entity: 0,22Mbps incoming, 0,07Mbps outgoing. > > 2nd entity: 0,15Mbps incoming, 0,02Mbps outgoing. > > 20 Kbps is too less for G.729. 8kbps is the raw G.729 data, but due to > packetization overhead you need 50* (20 byte payload + 20+8+12 > ip+udp+rtp header) = 24Kbps. > > In this case you might get weird behavior: usually you do not have > packet loss on 2G/3G connections as you have retransmissions on layer 2, > thus if the uplink bandwidth is not sufficient the sending device will > queue the packets in its sending buffer until the buffer is full and > only then it will drop the packets. (I once had increasing delay up to > several seconds as the sending device had a big sending buffer and did > not dropped packets but queued them) > > > 2. What could I check in configuration of pjmedia, pjsip in general and > > symbian_ua/_gui in particular to make it work on EDGE? > > I do not think it is possible with only 20kbps uplink bandwidth. You > could try G.723.1 which I remember worked great in the early days of my > 56k modem. > > Anyway if you want to analyze the problem in more detail you could use > tcpdump to capture the (S)RTP packets on the media relay and then > perform in Wireshark an RTP stream analysis. Then you will see typical > time intervall between packets, jitter and packet loss. As SRTP does not > encrypt the RTP header the analysis should work well. > > If you also want to listen to the stream you have to disable SRTP and > use RTP. Then you could listen to the audio (Wireshark does not support > G729 decoding directly, you have to do it manually as described on the > wiki: http://wiki.wireshark.org/HowToDecodeG729) > > regards > Klaus > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
