I took the rule from the wizard and changed it to prioritize the traffic
that comes from and is sent to my VoIP provider's IP address. Since I
know the traffic (no matter the port) is routed between my LAN and their
IP, the traffic is handled properly. This approach has worked well for
me in situations where the low delay bit is not always used.
HTH.
Charles Sprickman wrote:
Hi all,
Just looking at the shaper config and trying a few things out...
I noticed that the rules for VoIP do indeed match the SIP port (5060),
but I'm not seeing anything there to actually prioritize the RTP
streams. I've been doing a ton of VoIP stuff for work recently, so I'll
summarize:
-5060 is the port that SIP uses for signalling, in other words messages
like "you have a call from this number", your phone placing a call, call
waiting notification, etc. This is all UDP, so it is important to not
miss any of this stuff
-Next, you have a range of high ports (which seems fairly large and
random up in the 49000-50000) range, although it seems different phones,
switches and session border controllers may put these ports wherever
they wish. You can't easily follow these as the SIP signalling channel
tells both ends what ports to use to send and receive the audio streams
on. Again, UDP, and jitter and loss will degrade call quality.
Unless I'm missing something (like pf/altq looking at all ToS bits and
using those), you're missing the most important part of the VoIP call -
the actual audio streams...
Any thoughts on this? I'd be happy to just prioritize all traffic
to/from my phone's IP.
Thanks,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
