 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Clear Wireless
| reply to Matt
Re: I can see both sides here... 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. |
|
