Yes, many concerns. I would rather leave the PBX's behind firewalls and allow what's needed through. We don't always have permission to mess with the customer's router either, the corporate IT people several states away "will have to send someone out." Fine, now it's not my problem... until they get on site and don't have a clue what I'm talking about. So you don't know how to set up some DSCP based QoS on that Cisco? Here, let me Google that for you. Oh look, three seconds and I found a solution.

On 9/30/2014 12:56 PM, Mike Hammett via Af wrote:
Could also include exploits, firmware downloads, etc.



-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

------------------------------------------------------------------------
*From: *"Ken Hohhof via Af" <[email protected]>
*To: *[email protected]
*Sent: *Tuesday, September 30, 2014 12:54:13 PM
*Subject: *Re: [AFMUG] DiffServ and the internet

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 <mailto:[email protected]>
*Sent:* Tuesday, September 30, 2014 12:17 PM
*To:* [email protected] <mailto:[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
            <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.









Reply via email to