[Ekiga-list] Ekiga/sip and Linux traffic control (prioritizing sip)

Damien Sandras dsandras at seconix.com
Sun Jan 28 17:23:36 UTC 2007


Hi,

Le dimanche 28 janvier 2007 à 15:06 +0100, Wiktor Grębla a écrit :
> Hi.
> 
> First of all, thanks to all of you kind people who wrote this nice piece of software.
> 
> My question seems rather simple, but I'd like to ask for your advice as it's not really easy to me. 
> It all started when our wonderful DSL provider, polish (monopolistic) TPSA connected us 
> (6 of us) to the net with a not symmetrical DSL line (2Mbps/250kbps). Of course it's easy to 
> guess what happened, I wanted to be fair, and prepared a "tc" config with the equality 
> in mind, almost no restrictions on p2p. As a result, when i wanted to use Skype it all 
> went together with the outgoing p2p traffic to the same queue, resulting in... a lots of special 
> effects, also verbal, sometimes even vulgar ;).
> 
> Now i thought about Ekiga/sip, which seemed a good candidate to be "easily" filtered 
> and put into a separate class, possibly with a higher priority. Ekiga works without any tc rules
> modifications with the iLBC codec, but the sound quality could be better, so I'd like to 
> have a separate queue for it - the only question is - what should i put there and how. So far, 
> by looking at the wireshark sniffing results I see at least five different protocols used during 
> a single call: stun at the beginning, then sip/sdp, sip, some udp data, rtp, h.261...
> 
> The question is , what protocols have to be "shaped" and prioritized to assure better
> sound quality/different codec? (if you have tc examples I'll be of course more than happy 
> to take a look).
> 


I have never looked at tc closely. However, you have to give the
priority to outgoing RTP traffic.

The ports that will used are dynamic, but in a fixed range that you can
modify using gconf-editor by changing the value of
key /apps/ekiga/protocols/ports/rtp_port_range.

By default, ports in the 5000:5059 UDP range will be used.

That means that incoming traffic from your correspondant will arrive to
your machine with destination ports in that range (after rewriting of
the packet by the NAT stack), and that also means that ougoing traffic
from your machine to your correspondant will have source ports in that
range (before rewriting by the NAT stack).
-- 
 _      Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_  NOVACOM                 : http://www.novacom.be/
          FOSDEM                   : http://www.fosdem.org/
          SIP Phone             : sip:dsandras at ekiga.net
                       





More information about the ekiga-list mailing list