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
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
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
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
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@cyneric.com To: serusers@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@lists.iptel.org | http://lists.iptel.org/mailman/listinfo/serusers |
-
Ezequiel Colombo -
Lucas Aimaretto -
Nils Ohlmeier