11 May
2005
11 May
'05
9:48 p.m.
Hi all,
I've used for long time the QoS capabilities of linux for
shaping/prioritizing traffic. Now, i'm willing to prioritize rtp packets
in my lan, over the rest ot packets. I've used the u32 filters, but I
did not really found a nice way of "matching" a rtp packet. I read the
rfc so as to look at the rtp-header and found that the only field wich
does not change its value along time is the version-field. It is located
at the 29th byte ( with byte 0 at the IP heder first byte ). But it is a
really poor way of doing it, because there may be many other packets
wich will "get caugth" by this rule ...
any ideas ? any experience in the subject ...
Regards,
Lucas
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005
11 May
11 May
10:18 p.m.
Easiest solution: buy phones which have QoS tagging build in.
Second easiest solution: but your phones into a dedicated sub-network. Then it
is easy to identify phone traffic according to the IP.
Regards
NO
On Wednesday 11 May 2005 20:48, Lucas Aimaretto wrote:
Hi all,
I've used for long time the QoS capabilities of linux for
shaping/prioritizing traffic. Now, i'm willing to prioritize rtp packets
in my lan, over the rest ot packets. I've used the u32 filters, but I
did not really found a nice way of "matching" a rtp packet. I read the
rfc so as to look at the rtp-header and found that the only field wich
does not change its value along time is the version-field. It is located
at the 29th byte ( with byte 0 at the IP heder first byte ). But it is a
really poor way of doing it, because there may be many other packets
wich will "get caugth" by this rule ...
any ideas ? any experience in the subject ...
Regards,
Lucas
10:27 p.m.
Easiest solution: buy phones which have QoS tagging
build in.
Second easiest solution: but your phones into a dedicated
sub-network. Then it
is easy to identify phone traffic according to the IP.
Well ... first solution is nice ... but I have many phones allready.
Second one has many problems
- 1: If it is a softphone, I'll be giving high priority to the
PC holding the soft phone and I just want to prioritize RTP. service,
not all the services of that PC.
- 2: Lets say I use fix ports for softphone's rtp ... but kind
of messy if too many softphones.
- 3: If doing NAT, according to the KTPD ( Kernel Travelling
Packet Diagram ), I could not prioritize by source IP, because, at QoS
STAGE, the packet was allready nated, and so, all packets would match.
Regards,
Lucas
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005
10:43 p.m.
Then probably the only second possible identifier for RTP is the codec number.
Then your match option would sum up to UDP, starting from port 1024
(usually), RTP version number, and the codec range (from 0 to 110 to be
safe). Depends on you if that is sufficient.
Regards
NO
On Wednesday 11 May 2005 21:27, Lucas Aimaretto wrote:
Easiest
solution: buy phones which have QoS tagging build in.
Second easiest solution: but your phones into a dedicated
sub-network. Then it
is easy to identify phone traffic according to the IP.
Well ... first solution is nice ... but I have many phones allready.
Second one has many problems
- 1: If it is a softphone, I'll be giving high priority to the
PC holding the soft phone and I just want to prioritize RTP. service,
not all the services of that PC.
- 2: Lets say I use fix ports for softphone's rtp ... but kind
of messy if too many softphones.
- 3: If doing NAT, according to the KTPD ( Kernel Travelling
Packet Diagram ), I could not prioritize by source IP, because, at QoS
STAGE, the packet was allready nated, and so, all packets would match.
Regards,
Lucas 
11:49 p.m.
Lucas, if you are using rtpproxy the DSCP field of all media packets is set to
0xb8 (decimal 46, behavior EF) automatically.
If mediaproxy is used, the argument --tos= of mediaproxy.py can be usefull.
Now you can use tcindex in your tc filters or marks through iptables.
Regards
Ezequiel Colombo
----- Original Message -----
From: "Lucas Aimaretto" <lucas(a)cyneric.com>
To: <serusers(a)lists.iptel.org>
Sent: Wednesday, May 11, 2005 3:48 PM
Subject: [Serusers] QoS with rtp
| Hi all,
|
| I've used for long time the QoS capabilities of linux for
| shaping/prioritizing traffic. Now, i'm willing to prioritize rtp packets
| in my lan, over the rest ot packets. I've used the u32 filters, but I
| did not really found a nice way of "matching" a rtp packet. I read the
| rfc so as to look at the rtp-header and found that the only field wich
| does not change its value along time is the version-field. It is located
| at the 29th byte ( with byte 0 at the IP heder first byte ). But it is a
| really poor way of doing it, because there may be many other packets
| wich will "get caugth" by this rule ...
|
| any ideas ? any experience in the subject ...
|
| Regards,
|
| Lucas
|
| --
| No virus found in this outgoing message.
| Checked by AVG Anti-Virus.
| Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005
|
|
| _______________________________________________
| Serusers mailing list
| serusers(a)lists.iptel.org
| http://lists.iptel.org/mailman/listinfo/serusers
|
7137
days inactive
7137
days old
4 comments
3 participants
participants (3)
-
Ezequiel Colombo -
Lucas Aimaretto -
Nils Ohlmeier