Hello, As far as I could understand, I was able to configure and compile symbian_ua_gui with TLS, VAS and G729 protocol to work with local Kamailio based server, all communications go through media-proxy, SRTP (on the same local server). In 3G mobile networks, everything works just fine and quality is superb. Now what I see when connecting two entities (Nokia E51) WHEN CONNECTED THROUGH EDGE (the place where both entities were located has *no* 3G access and this was simulated by switching the phones) there is a very bad quality of audio. Either the packets are too big for such a slow connection (you can mostly here about a half of each packet then overlapped by the next one) or my configuration lacks some other vital parameters. It is not like the behavior we hear in GSM connection ("robotizing", "bubbling") - just packets are overlapped. 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. According to at least this table ( http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml) the link has enough bandwidth to serve one connection. Even 9Kbps each direction should be enough. The questions are: 1. Whether anyone tested symbian_ua_gui or symbian_ua in EDGE phone mode, not 3G or WiFi? 2. What could I check in configuration of pjmedia, pjsip in general and symbian_ua/_gui in particular to make it work on EDGE? Thanks in advance, Dmitry.

Dmitry- > As far as I could understand, I was able to configure and > compile symbian_ua_gui with TLS, VAS and G729 protocol to work with local > Kamailio based server, all communications go through media-proxy, SRTP (on > the same local server). > > In 3G mobile networks, everything works just fine and quality is superb. > > Now what I see when connecting two entities (Nokia E51) WHEN CONNECTED > THROUGH EDGE (the place where both entities were located has *no* 3G access > and this was simulated by switching the phones) there is a very bad quality > of audio. > > Either the packets are too big for such a slow connection (you can mostly > here about a half of each packet then overlapped by the next one) or my > configuration lacks some other vital parameters. It is not like the behavior > we hear in GSM connection ("robotizing", "bubbling") - just packets are > overlapped. > > In general, the main problem with mobile networking is that you have a > rather wide Inbound channel and very narrow Outbound channel. And the other main problem is that many carriers block (or impair) voice transport over non-voice channels. In that case you have to encrypt or otherwise "hide" RTP (and sometimes SIP) packets on data channels. Also when you say you can "hear a packet" that's impossible because you're talking about 10 or 20 msec length of time -- less than 1/50th of a second. My suggestion would be to put Wireshark on either side of Kamailio and find out what is actually happening to your packets. If it's a deliberate impairment you should be able to tell. -Jeff > 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. > > According to at least this table ( > http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml) > the link has enough bandwidth to serve one connection. Even 9Kbps each > direction should be enough. > > The questions are: > 1. Whether anyone tested symbian_ua_gui or symbian_ua in EDGE phone mode, > not 3G or WiFi? > 2. What could I check in configuration of pjmedia, pjsip in general and > symbian_ua/_gui in particular to make it work on EDGE? > > Thanks in advance, > Dmitry.

Jeff, do you mean that operator may impair packets on edge and leave intact switching to umts? Dmitry. On 5/10/10, Jeff Brower <jbrower@signalogic.com> wrote: > Dmitry- > >> As far as I could understand, I was able to configure and >> compile symbian_ua_gui with TLS, VAS and G729 protocol to work with local >> Kamailio based server, all communications go through media-proxy, SRTP (on >> the same local server). >> >> In 3G mobile networks, everything works just fine and quality is superb. >> >> Now what I see when connecting two entities (Nokia E51) WHEN CONNECTED >> THROUGH EDGE (the place where both entities were located has *no* 3G >> access >> and this was simulated by switching the phones) there is a very bad >> quality >> of audio. >> >> Either the packets are too big for such a slow connection (you can mostly >> here about a half of each packet then overlapped by the next one) or my >> configuration lacks some other vital parameters. It is not like the >> behavior >> we hear in GSM connection ("robotizing", "bubbling") - just packets are >> overlapped. >> >> In general, the main problem with mobile networking is that you have a >> rather wide Inbound channel and very narrow Outbound channel. > > And the other main problem is that many carriers block (or impair) voice > transport over non-voice channels. In that > case you have to encrypt or otherwise "hide" RTP (and sometimes SIP) packets > on data channels. Also when you say you > can "hear a packet" that's impossible because you're talking about 10 or 20 > msec length of time -- less than 1/50th of > a second. > > My suggestion would be to put Wireshark on either side of Kamailio and find > out what is actually happening to your > packets. If it's a deliberate impairment you should be able to tell. > > -Jeff > >> 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. >> >> According to at least this table ( >> http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml) >> the link has enough bandwidth to serve one connection. Even 9Kbps each >> direction should be enough. >> >> The questions are: >> 1. Whether anyone tested symbian_ua_gui or symbian_ua in EDGE phone mode, >> not 3G or WiFi? >> 2. What could I check in configuration of pjmedia, pjsip in general and >> symbian_ua/_gui in particular to make it work on EDGE? >> >> Thanks in advance, >> Dmitry. > > -- Sent from my mobile device

Dmitry- > Jeff, do you mean that operator may impair packets on edge and leave > intact switching to umts? Yes if the data packets are RTP packets (and possibly SIP, I've heard from some customers lately that a few carriers are using more sophisticated blocking algorithms). But again, only some carriers might do it. You could be having some other problem. This is why I suggest Wiresharking so you can post debug samples of what you're seeing -- maybe some packets out of sequence, maybe some missing, etc. It's hard to guess on something like this. -Jeff > On 5/10/10, Jeff Brower <jbrower@signalogic.com> wrote: >> Dmitry- >> >>> As far as I could understand, I was able to configure and >>> compile symbian_ua_gui with TLS, VAS and G729 protocol to work with local >>> Kamailio based server, all communications go through media-proxy, SRTP (on >>> the same local server). >>> >>> In 3G mobile networks, everything works just fine and quality is superb. >>> >>> Now what I see when connecting two entities (Nokia E51) WHEN CONNECTED >>> THROUGH EDGE (the place where both entities were located has *no* 3G >>> access >>> and this was simulated by switching the phones) there is a very bad >>> quality >>> of audio. >>> >>> Either the packets are too big for such a slow connection (you can mostly >>> here about a half of each packet then overlapped by the next one) or my >>> configuration lacks some other vital parameters. It is not like the >>> behavior >>> we hear in GSM connection ("robotizing", "bubbling") - just packets are >>> overlapped. >>> >>> In general, the main problem with mobile networking is that you have a >>> rather wide Inbound channel and very narrow Outbound channel. >> >> And the other main problem is that many carriers block (or impair) voice >> transport over non-voice channels. In that >> case you have to encrypt or otherwise "hide" RTP (and sometimes SIP) packets >> on data channels. Also when you say you >> can "hear a packet" that's impossible because you're talking about 10 or 20 >> msec length of time -- less than 1/50th of >> a second. >> >> My suggestion would be to put Wireshark on either side of Kamailio and find >> out what is actually happening to your >> packets. If it's a deliberate impairment you should be able to tell. >> >> -Jeff >> >>> 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. >>> >>> According to at least this table ( >>> http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml) >>> the link has enough bandwidth to serve one connection. Even 9Kbps each >>> direction should be enough. >>> >>> The questions are: >>> 1. Whether anyone tested symbian_ua_gui or symbian_ua in EDGE phone mode, >>> not 3G or WiFi? >>> 2. What could I check in configuration of pjmedia, pjsip in general and >>> symbian_ua/_gui in particular to make it work on EDGE? >>> >>> Thanks in advance, >>> Dmitry. >> >> > > -- > Sent from my mobile device >

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

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@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org