said by bzmeteorite :

On one hand, the fact that CDV is on its own channel (as I understand from comments from the previous article) may make some inclined (FCC, et al.) to regulate it as a telco service. If Comcast started to put it's Digital Voice service inline with data (sharing the channel with internet), consumers and regulators would cry out and start lawsuits if their line became "de-prioritized" and they tried calling 911 and as a result of their de-prioritization, their 911 call dropped due to latency or packet loss.

Of course, they could prioritize all VoIP possible on the data channel, but what happens if a competitor uses a proprietary technology that prevents Comcast from identifying their voice service? Or when people or regulators start crying about the usage of DPI to identify VoIP? Net neutrality?

I just don't see a realistic middle ground without someone getting hurt in some way.

There is a simple solution to the 3rd party VoIP situation. When I use such an application, I am connecting with a Server run by the VoIP Provider. Thus Comcast KNOWS that this is a VoIP Session and can serve it over the same channel as they use for THEIR CDV service.

said by RARPSL :

There is a simple solution to the 3rd party VoIP situation. When I use such an application, I am connecting with a Server run by the VoIP Provider. Thus Comcast KNOWS that this is a VoIP Session and can serve it over the same channel as they use for THEIR CDV service. I know that this might be seen as violating some aspects of Network Neutrality but so long as there is no blackmail fees being extorted from the VoIP Providers and ALL VoIP traffic flows unrestricted over the 2nd channel, I see no real problem.

said by djrobx :

Nope, sorry, that would be treating VOIP differently than other internet traffic, which is against net neutrality principles.

said by djrobx :

Nope, sorry, that would be treating VOIP differently than other internet traffic, which is against net neutrality principles.

said by espaeth :

Exactly. Internet network neutrality means you can't hinder nor help Internet traffic based on protocol, as to prioritize VoIP is to deprioritize other Internet traffic.

The core of the matter is this: CDV is not an Internet-based service. You cannot .

said by videoOip :

Do all the same principals go for the Video over IP priority which is done by FiOS?

If I have my Internet Video app, FiOS must give it equal treatment as their HD ESPN signal?

said by RARPSL :

Yes you can and do "access the CDV infrastructure from outside of Comcast's network". At some point, the traffic leaves the Comcast network and flows over the Internet or some TelCo's network (unless both sides of the phone call are CDV numbers). VoIP is Voice over IP and thus IS an Internet-Based service.

said by bzmeteorite :

And how would they absolutely know that it's to a VoIP service?

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.

said by videoOip :

Do all the same principals go for the Video over IP priority which is done by FiOS?

If I have my Internet Video app, FiOS must give it equal treatment as their HD ESPN signal?