Consumer Advocates Embrace FCC's Latest Comcast Inquiry > I can see both sides here...

said by RARPSL:

How do I know that I am probably a HTTP session? The first hint is that I am talking to Port80 or 443. In the case of ViOP, the session would be going to the designated VoIP Port.

said by espaeth:

There is no designated VoIP port -- UDP ports for RTP sessions are assigned dynamically by the session border controllers during each call setup. That's why VoIP providers have you open up massive firewall ranges like UDP ports 10,000 - 20,000.

said by Matt:

There is a control port however for SIP, UDP 5060.

said by espaeth:

Which is all but useless to identify at a port-level. Giving priority to your SIP signaling for call setup/tear-down and not the voice-carrying RTP streams gains you nothing from an end-user perspective.

said by Matt:

There are ways to make use of it -- you could identify the destination of the port 5060 session and prioritize all traffic to that IP. That doesn't even require DPI since the header has to be read anyway.

said by espaeth:

Not quite -- there's a few problem here.

1) There is no way to configure that type of operation in standard Cisco IOS or Juniper JunOS devices.

2) The session border controller doesn't need to be same point of termination as the RTP streams. If you use Viatalk, for instance, your device talks SIP to their call managers but the calls hand off to directly to Level(3) gateways -- the destination IP of the RTP stream is delivered in the SIP INVITE.

3) This scheme is easy to exploit. Take the new uTP UDP-based bit torrent protocol -- under this scheme all the client would have to do is send a port 5060 packet to look like a SIP setup and then the UDP-based P2P flow that follows could be classified as protected VoIP traffic.