Surely the SIP messages will contain the IP addresses of the
re-invite for the RTP stream. Any way to reliably pull those?
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
------------------------------------------------------------------------
*From: *"Adam Moffett via Af" <[email protected]>
*To: *[email protected]
*Sent: *Wednesday, October 1, 2014 8:40:14 AM
*Subject: *Re: [AFMUG] DiffServ and the internet
I looked at the same thing :) The RTP header is pretty short.
You've technically got 12 bytes of RTP header, but some of it is
sequence number and timestamp which I don't know how you could match
on. You can make reasonable guesses about what the first 16 bits are
going to be, after that you really only know the length of the rest
of the header and the length of the payload. I personally could not
write a regexp that would be substantially more accurate than
matching the whole packet length. Maybe ask whoever wrote wireshark.
I saw this L7 match rule somewhere:
^\x80[\x01-"`-\x7f\x80-\xa2\xe0-\xff]?..........*\x80
but the plain english version of that is something like, "the
sequence starts with 0x80, then there's another byte that might match
several patterns, and then there are some more bytes, and then
another 0x80". Which I don't think is much better than just matching
the length. It also doesn't match any of my actual VoIP traffic anyway.
Here's another thought: You can easily match SIP packets. They
contain plain text headers that you can match. You could just match
port 5060, but Google Voice and 8x8 both stopped using the standard
port, so instead you look for content containing SIP Invite or some
such. You could add matching IP addresses to an address list with a 1
hour expiration, then subsequent rules look for the appropriately
sized UDP packets to and from the IP addresses that you previously
saw sending SIP packets.
/ip firewall mangle
add action=add-src-to-address-list address-list=recentSIPInvite \
address-list-timeout=1h chain=prerouting content=INVITE disabled=no \
protocol=udp
add action=accept chain=prerouting disabled=no packet-size=200
protocol=udp \
src-address-list=recentSIPInvite
add action=accept chain=prerouting disabled=no dst-address-list=\
recentSIPInvite packet-size=200 protocol=udp
The above matches all the RTP traffic in my office. I could probably
be more accurate than watching for the string "INVITE" and I could
narrow the field of packets that are worth spending CPU on content
matching.....but it works.
Is there no way to make an L7 rule to do this?
Here's what Wireshark gives me. Can't I do something with this
information?
On 9/30/2014 4:05 PM, Adam Moffett via Af wrote:
So one simple workaround I saw was was to match UDP packets
at specific sizes. Every single G.711 RTP packet my phone
sends is a UDP packet that's 200 bytes every time. I'm sure
it would eventually overmatch something, but it's simple and
low cost. The example I saw was matching every UDP packet
from 100-400 bytes that wasn't already matched by some other
criteria. A quick test here worked with a rule set to match
at exactly 200 bytes....so I'm thinking rather than saying
every mid size UDP packet is VoIP that maybe I'll match the
specific sizes of packets in common codecs with 20ms frame sizes.
Yeah, it's more complicated than just giving the PBX a
public and setting DSCP on every packet destined to that
IP. I can't have everything end up in the HP queue, that
will create more problems than the one I'm trying to
solve. I need to figure out a way to identify the traffic
and mangle DSCP on at the edge routers.
On 9/30/2014 11:04 AM, Adam Moffett via Af wrote:
....but like George, I would also be interested in
some sort of rule that would match RTP voice
traffic. I don't see any easy way to do it, but
wireshark seems to pick up on it reliably, so I guess
there's a way.
+1
Seems like the easiest answer.
On 9/30/2014 11:05 AM, Ken Hohhof via Af wrote:
Is the company’s PBX behind their firewall?
If you give it a dedicated IP address, then
you can tag based on destination IP.
*From:* George Skorup (Cyber Broadcasting)
via Af <mailto:[email protected]>
*Sent:* Tuesday, September 30, 2014 9:55 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] DiffServ and the internet
These are business customers with on-site
PBXs with a VoIP Innovations SIP trunk. Yeah,
if we were running a local switch, then this
problem would be a whole lot easier to solve,
but that's not what I have to work with at
this point.
As far as I can tell, there's no easy way to
identify the VoIP Innovations audio streams.
They come from tons of different source
address and use random ports from 10000 to
20000. And it's a mix of G711 and G729.
No idea, I'm just the network guy.
On 9/30/2014 9:28 AM, Ken Hohhof via Af wrote:
That’s what I do, there’s another way?
We put customer ATAs on private IPs so it
wouldn’t work if traffic bypassed our server.
Is there a configuration parameter on the
SIP trunk that tells it to send RTP
traffic directly to the endpoint?
We also have a multisite business
customer that uses a hosted VoIP service
(Star2Star) with an appliance at each
site, we give each appliance its own
public IP and tag traffic to those IPs.
*From:* Adam Moffett via Af
<mailto:[email protected]>
*Sent:* Tuesday, September 30, 2014 9:03 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [AFMUG] DiffServ and the
internet
I've been cheating up until this point.
If you force the audio to be bridged
through your own server then you can tag
all the traffic that goes to and from
that server. It doesn't seem to make a
huge difference versus having RTP go
straight to the carrier. If you're not
transcoding then the added CPU usage is
minimal. Faxing seems to work better if
I'm not bridging the audio, but why am I
faxing anyway, right?
I tried all kinds of stuff tonight,
none were any good. I wonder if
there's a way on MT to snoop SIP
messages and look for the SIP contact
IPs and mark those. Seems tricky. And
I R no smrt enuf.
On 9/29/2014 9:37 PM, Chris Fabien
via Af wrote:
Packet size and rate is pretty
consistent right? Just a thought...
On Mon, Sep 29, 2014 at 8:05 PM,
George Skorup (Cyber
Broadcasting) via Af
<[email protected]
<mailto:[email protected]>> wrote:
Speaking of DSCP and carriers
zeroing it in the middle, I
have some VoIP Innovations
trunks. I know where the SIP
messages are coming from, so
I can mangle a DSCP value
back onto those packets at
ingress. But the RTP traffic
comes from all over the
freakin place, tons of
different source address,
never the same. I've asked if
they could provide a list and
pretty much got a no.
Anybody have any ideas? Any
way for a MT to identify an
RTP stream and then
dynamically add a mangle rule
to change the DSCP value? My
MT script-fu is not strong.
