Time for me to complain about the use of the English language again. Today's complaint: the misleading jargon surrounding SIP.
SIP ("Session Initiation Protocol") is a protocol which can allow two devices to communicate, usually to set up a VoIP call.
Applying old-school telephony terminology to VoIP has created misunderstanding. A “SIP trunk” is not actually a trunk, but it replaces trunks, so lazy telecom folks gave it that name. SIP does not have “call paths,” but because the simultaneous-user limits behave like old call paths, people use that term.
SIP is not involved in the actual transport of voice or anything else. It just sets up (and later tears down) the connection between two devices. Once the connection is established, communication goes directly between the two phones using RTP, with no involvement from the provider’s SIP infrastructure until the call is terminated. (When you talk into your VoIP phone, your phone turns that sound into packets and sends them directly to the other phone.)
You can’t run data over a SIP trunk. First of all, there’s no “trunk,” just a license to use a service provider’s SIP servers to set up and tear down calls. Second, SIP cannot handle, say, an HTTP request, so you can’t browse the Web using SIP. We don’t use SIP for anything but VoIP (and maybe some videoconferencing).
It’s like saying that you have an “HTTP trunk” that carries data and audio/video. It’s a protocol, not a transport medium. And yes, the use of HTTP does result in you getting to watch Nyan Cat videos, but HTTP’s involvement is to give your browser the info that it needs to get the video from a video server.
So I propose that we outlaw the use of terminology like "SIP trunk" or "SIP call path" in the E-Rate program.
Looking a little deeper, the distinction between “voice” and “data” is mighty fuzzy. Your VoIP end-user device knows it’s a phone call, and maybe a gateway in your building knows, and your service provider’s SIP infrastructure is aware it’s a call when setting it up and tearing it down, but all the other devices involved (routers, switches, etc.) just see your phone call as a bunch of packets (maybe high-priority packets).
I’m a visual guy, so I find looking at the OSI Model clears things up for me.
SIP ("Session Initiation Protocol") is a protocol which can allow two devices to communicate, usually to set up a VoIP call.
Applying old-school telephony terminology to VoIP has created misunderstanding. A “SIP trunk” is not actually a trunk, but it replaces trunks, so lazy telecom folks gave it that name. SIP does not have “call paths,” but because the simultaneous-user limits behave like old call paths, people use that term.
SIP is not involved in the actual transport of voice or anything else. It just sets up (and later tears down) the connection between two devices. Once the connection is established, communication goes directly between the two phones using RTP, with no involvement from the provider’s SIP infrastructure until the call is terminated. (When you talk into your VoIP phone, your phone turns that sound into packets and sends them directly to the other phone.)
You can’t run data over a SIP trunk. First of all, there’s no “trunk,” just a license to use a service provider’s SIP servers to set up and tear down calls. Second, SIP cannot handle, say, an HTTP request, so you can’t browse the Web using SIP. We don’t use SIP for anything but VoIP (and maybe some videoconferencing).
It’s like saying that you have an “HTTP trunk” that carries data and audio/video. It’s a protocol, not a transport medium. And yes, the use of HTTP does result in you getting to watch Nyan Cat videos, but HTTP’s involvement is to give your browser the info that it needs to get the video from a video server.
So I propose that we outlaw the use of terminology like "SIP trunk" or "SIP call path" in the E-Rate program.
Looking a little deeper, the distinction between “voice” and “data” is mighty fuzzy. Your VoIP end-user device knows it’s a phone call, and maybe a gateway in your building knows, and your service provider’s SIP infrastructure is aware it’s a call when setting it up and tearing it down, but all the other devices involved (routers, switches, etc.) just see your phone call as a bunch of packets (maybe high-priority packets).
I’m a visual guy, so I find looking at the OSI Model clears things up for me.
|
Each layer translates the info into a format that the next layer can work with. When an application wants to send info to another node, it works its way down the stack, through a variety of protocols which transform it until it reaches the Physical layer, which is a fiber or wire. When that signal arrives at the remote node, it works its way back up the stack, being transformed back into something the application at the other end can use. |
Your connection to your ISP operates at the Data Link Layer: a signal on a wire (or fiber). So it seems seems kind of nonsensical to cost-allocate that connection based on whether some of those signals used to be voice (and will be again once they've been transformed by the layers at the other end).
Why does it matter? Because the ESL says you have to apply the voice discount reduction to "circuit capacity dedicated to providing voice services" (which is language lifted from the E-Rate Modernization Order). The mistaken belief that SIP is some kind of trunk leads people to believe that it is dedicated to voice and that you can determine the cost of that trunk and cost-allocate. There is no "dedicated" capacity in a typical IP-over-Ethernet network.
And now a meta-rant:
Who the hell came up with "SIP"? First off, in the name of a protocol, "IP" should mean "Internet Protocol"; everyone who sees "IP" in an acronym is going to assume it means IP. And why use the word "Session"? "Session" already has a meaning in networking (as you can see in the picture above). How about we rename it "Multimedia Connection Establishment Protocol" or MCEP? Not as catchy, but also not as confusing.
No comments:
Post a Comment