1 edit | reply to RARPSL
Re: I can see both sides here... 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. Even such a system would likely require hardware or (maybe) firmware upgrades, probably on the CPE side (mind you, I am no expert of DOCSIS, but that makes practical sense). And how would they absolutely know that it's to a VoIP service? There is always the possibility of an oversight with DPI especially if one VoIP provider a custom proprietary solution, in which case I'm sure some sue-happy consumer or company would take advantage of. Say there was a directory of VoIP services, that could work, but that's more administrative overhead and likely even more chance of someone crying anti-competitive/net neutrality.
I kinda like another poster's idea that since CDV doesn't travel the public net, it shouldn't be expected to be treated the same as VoIP that runs over the public net. Then again we're back to square one when the FCC requires it be regulated as a telco service since it's on a different channel because of their definition.
--
What happens when you combine common sense and an outspoken personality? |
|
|
|
 RARPSL
join:1999-12-08
Suffern, NY | said by bzmeteorite:And how would they absolutely know that it's to a VoIP service? 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. As I stated in my comment, the IPN that the connection is going to is that of the VoIP's Server so an attempt to connect there is a GOOD indication of an VoIP session (especially in conjunction with the VoIP Port at the Server side). |
|
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Clear Wireless
| 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. 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. |
|
 MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by espaeth: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. 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. There is a control port however for SIP, UDP 5060. |
|
espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Clear Wireless
| said by Matt:There is a control port however for SIP, UDP 5060. 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. |
|
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by espaeth:said by Matt:There is a control port however for SIP, UDP 5060. 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. 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. |
|
espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Clear Wireless
| 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. 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. |
|
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by espaeth: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. 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. 1) It could be added.
2) Then Viatalk may be the exception -- or perhaps my Nuvio service is since the SIP destination is the same as the RTP destination. VoIP providers could simply add an RTP proxy.
3) I don't know about you, but I wouldn't want my torrent session limited to a hundred kbps or so. And before you say that's per session, it's pretty easy to identify 100+ simultaneous "VoIP" sessions.
FWIW, I'm not holding this up an the ultimate answer, I'm just using it to illustrate there are ways to identify and prioritize 3rd party VoIP sessions. |
|
