You’re worried about web GUI traffic like people retrieving their voicemail via 
the web from off your network?  Or something else?

Perhaps you could further classify it as UDP and ports >1024, probably >10000.

From: George Skorup (Cyber Broadcasting) via Af 
Sent: Tuesday, September 30, 2014 12:17 PM
To: [email protected] 
Subject: Re: [AFMUG] DiffServ and the internet

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 
      Sent: Tuesday, September 30, 2014 9:55 AM
      To: [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 
        Sent: Tuesday, September 30, 2014 9:03 AM
        To: [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]> 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.













Reply via email to