As I mentioned previously, devices on a SIP network are called User Agents. A User Agent Client and a User Agent Server are both required for communication.
SIP defines three server elements: a Registrar, a Proxy Server, or a Redirect Server. A Registrar server accepts REGISTER requests and is typically co-located with a proxy server or a redirect server. It can offer location services, and registers SIP parties in a SIP domain. A Proxy Server functions as both a server and a client that makes and receives requests on behalf of other SIP clients. It supports requests locally or forwards them to other servers. It can interpret and re-write a SIP request message before forwarding it to another server or User Agent. A Redirect server will accept SIP requests, read the information and map the address in the request to the next hop. It will then return an appropriate message to the client. The client can then directly contact the appropriate next hop. It does not forward SIP requests to other servers and it does not accept calls. A SIP Redirect Server will only respond with 3xx series responses. It is important to note that these three types of SIP servers are logically, and not physically distinct.
In addition to the three server types and the User Agents that are present in a SIP Network, there are also Session Border Controllers (SBC) and gateways on the network. A Session Border Controller is inserted into the signaling path and handles the signaling and media being sent across the network. The SBC can also perform anti-tromboning functions. Tromboning occurs when two devices on the same subnet are both trying to connect through a third server when they should be allowed to connect directly. By directing the two devices to speak directly to each other the trunks can be opened up for use by other devices. An SBC can also implement transcoding when required, but this is not recommended, as was discussed previously. An SBC can restrict call flow or allow connections to exist where they would not have otherwise been able to exist (due to a firewall between the two end-points, or other security policies). It is also interesting to note that the Session Border Controller can enforce interception of network sessions. This is interesting because, without the SBC, there would be no way to intercept the flow of data between two SIP devices as can be required by various law enforcement agencies. This is because under normal circumstances SIP will try to have end-points communicate directly with each other. A Gateway simply acts as a connecting point between a SIP network and a dissimilar network, such as H.323 or PSTN. Any calls that are being sent out to the PSTN will have to go through a gateway.
Showing posts with label VoIP. Show all posts
Showing posts with label VoIP. Show all posts
Issues facing WLAN technology
It should come as no surprise to anyone that there are several issues faced with a WLAN deployment. These issues can be very complex, so a careful understanding of RF technology is needed to successfully deploy a WLAN. There are several factors that can affect the radio waves being sent out by WLAN devices, causing corruption, loss, gain, and many other issues. I will discuss these issues now.
First I would like to touch upon loss. Loss occurs when there is a decrease in signal strength. Loss can occur both before and after the signal hits the air. It can happen for a variety of reasons, such as resistance in electrical cables and obstacles. Like all electrical signals, RF signals weaken as they get further away from the source. Obstacles, such as brick walls, will decrease the strength as well. As an example, the apartment in which I live is in a brick building. Forty years ago, when the building was converted from a single-family home into a multi-unit dwelling, there was an extension built onto the back of this brick building to provide a kitchen area as well as a fire escape. I have most of my computers in the front half of this building, but we often take my wife’s laptop into the back part of the building, as it is handy to look up recipes and perform other tasks while in the kitchen or dining room. Something I noticed right away was that as soon as I left the room containing our wireless router the signal strength went from five bars down to two bars. By the time I reached the back of the house I was no longer able to access the wireless network, as the signal strength had degraded so much in that short distance. When the signal passed through the brick wall, I experienced obstruction loss. As I moved further away from the access point I experienced path loss.
Gain is another factor affecting RF behaviors. Gain is almost the opposite of loss, but not quite. Gain is an increase in the amplitude of the RF signal. It can be caused by the use of an amplifier or a high antenna. An antenna can not amplify a signal, but it can focus it, thereby increasing the amplitude. The ability of an antenna to focus a signal is called gain. It is possible that a device may be able to receive a signal that has significant gain but it will not be able to establish two-way communication. If you are implementing a situation where gain is required, it is optimal to implement gain on both ends.
Lobe refers to the amount of coverage area of an RF signal sent from an antenna. An antenna with gain can focus the area of coverage and narrow (or focus) the lobe so that it has less coverage vertically, but more coverage horizontally. This will increase the range of the signal while decreasing the amount of up-and-down coverage area. This is ideal for long-range wireless communications from one point to another, as the signal can be focused directly on the receiving antenna.
Refraction occurs when an RF signal passes through an obstacle and bends. Refraction can cause the RF signal to be diverted from its intended destination. This is particularly a problem on long-distance point-to-point links.
Diffraction occurs when an RF signal bends as it passes around an obstacle. Diffraction can result in the distortion of an RF signal.
Scattering occurs when an RF signal bounces off a rough surface, or off of particles in the air. Both situations cause the RF signal to scatter in many directions.
Absorption occurs when an RF signal is absorbed by an object and is not allowed to pass through at all. The problem here should be obvious!
Finally, reflection can occur when an RF signal bounces off a large obstacle, causing degradation of signal strength. The receiving end receives the data through both the direct wave and the reflected wave and attempts to process both signals simultaneously. This can cause a multi-path signal, which can become a serious problem. If the multi-path signal is 180 degrees out of phase with the original signal, the two signals can cancel each other out! Mathematically speaking, the degradation of signal strength occurs at a fourth power of distance, or Strength = -1/d4.
There are also some delay issues that are expected with a WLAN. As mentioned earlier, WLANs use ACK packets to signify that the data has been correctly received. If a packet is not received, an automatic repeat request (ARQ) is used by the WLAN to request the retransmission of the packet. In a VoIP environment delays can be experienced while the data is being retransmitted. Delays can also be experienced because forward and reverse direction MAC flows that the WLAN uses to maintain link reliability and control use bandwidth as well. Since stations are always contending for access to the media we can experience further delays. Typical WLAN delays include:
1. Interframe Space (50 μs)
2. Back off (average of 80 μs)
3. Synchronization Preamble (192 μs)
4. Data (approximately 171 μs)
5. Gap between Data and ACK (10 μs)
6. Next Preamble (192 μs)
7. MAC ACR (11 μs)
As we can see, we can expect an average delay of 706 μs. In addition we can expect to see further delays on our WLAN as we add more MUs to the network, each trying to compete with each other for access to the medium.
First I would like to touch upon loss. Loss occurs when there is a decrease in signal strength. Loss can occur both before and after the signal hits the air. It can happen for a variety of reasons, such as resistance in electrical cables and obstacles. Like all electrical signals, RF signals weaken as they get further away from the source. Obstacles, such as brick walls, will decrease the strength as well. As an example, the apartment in which I live is in a brick building. Forty years ago, when the building was converted from a single-family home into a multi-unit dwelling, there was an extension built onto the back of this brick building to provide a kitchen area as well as a fire escape. I have most of my computers in the front half of this building, but we often take my wife’s laptop into the back part of the building, as it is handy to look up recipes and perform other tasks while in the kitchen or dining room. Something I noticed right away was that as soon as I left the room containing our wireless router the signal strength went from five bars down to two bars. By the time I reached the back of the house I was no longer able to access the wireless network, as the signal strength had degraded so much in that short distance. When the signal passed through the brick wall, I experienced obstruction loss. As I moved further away from the access point I experienced path loss.
Gain is another factor affecting RF behaviors. Gain is almost the opposite of loss, but not quite. Gain is an increase in the amplitude of the RF signal. It can be caused by the use of an amplifier or a high antenna. An antenna can not amplify a signal, but it can focus it, thereby increasing the amplitude. The ability of an antenna to focus a signal is called gain. It is possible that a device may be able to receive a signal that has significant gain but it will not be able to establish two-way communication. If you are implementing a situation where gain is required, it is optimal to implement gain on both ends.
Lobe refers to the amount of coverage area of an RF signal sent from an antenna. An antenna with gain can focus the area of coverage and narrow (or focus) the lobe so that it has less coverage vertically, but more coverage horizontally. This will increase the range of the signal while decreasing the amount of up-and-down coverage area. This is ideal for long-range wireless communications from one point to another, as the signal can be focused directly on the receiving antenna.
Refraction occurs when an RF signal passes through an obstacle and bends. Refraction can cause the RF signal to be diverted from its intended destination. This is particularly a problem on long-distance point-to-point links.
Diffraction occurs when an RF signal bends as it passes around an obstacle. Diffraction can result in the distortion of an RF signal.
Scattering occurs when an RF signal bounces off a rough surface, or off of particles in the air. Both situations cause the RF signal to scatter in many directions.
Absorption occurs when an RF signal is absorbed by an object and is not allowed to pass through at all. The problem here should be obvious!
Finally, reflection can occur when an RF signal bounces off a large obstacle, causing degradation of signal strength. The receiving end receives the data through both the direct wave and the reflected wave and attempts to process both signals simultaneously. This can cause a multi-path signal, which can become a serious problem. If the multi-path signal is 180 degrees out of phase with the original signal, the two signals can cancel each other out! Mathematically speaking, the degradation of signal strength occurs at a fourth power of distance, or Strength = -1/d4.
There are also some delay issues that are expected with a WLAN. As mentioned earlier, WLANs use ACK packets to signify that the data has been correctly received. If a packet is not received, an automatic repeat request (ARQ) is used by the WLAN to request the retransmission of the packet. In a VoIP environment delays can be experienced while the data is being retransmitted. Delays can also be experienced because forward and reverse direction MAC flows that the WLAN uses to maintain link reliability and control use bandwidth as well. Since stations are always contending for access to the media we can experience further delays. Typical WLAN delays include:
1. Interframe Space (50 μs)
2. Back off (average of 80 μs)
3. Synchronization Preamble (192 μs)
4. Data (approximately 171 μs)
5. Gap between Data and ACK (10 μs)
6. Next Preamble (192 μs)
7. MAC ACR (11 μs)
As we can see, we can expect an average delay of 706 μs. In addition we can expect to see further delays on our WLAN as we add more MUs to the network, each trying to compete with each other for access to the medium.
Wireless LAN
The Wireless LAN is a relatively new technology that uses radio frequencies as a medium instead of physical wires. WLANs use the same principles as an Ethernet network, with a couple of minor changes. Ethernet uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This is not a possibility, as there is no way to accurately detect a collision on a Radio Frequency. Instead, WLAN technology uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to ensure that packets are not dropped due to a collision. A WLAN device, or Mobile Unit (MU), uses two methods of collision avoidance: Physical Carrier Sense and Virtual Carrier Sense.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Wireless LAN
The Wireless LAN is a relatively new technology that uses radio frequencies as a medium instead of physical wires. WLANs use the same principles as an Ethernet network, with a couple of minor changes. Ethernet uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This is not a possibility, as there is no way to accurately detect a collision on a Radio Frequency. Instead, WLAN technology uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to ensure that packets are not dropped due to a collision. A WLAN device, or Mobile Unit (MU), uses two methods of collision avoidance: Physical Carrier Sense and Virtual Carrier Sense.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Network Policies and Management
A Network Policy is a set of rules governing the network. It can include traffic monitoring and controlling mechanisms. We should implement network policies in order to help implement QoS in a controlled manner. Network policies can also help with security implementations.
A Policy Decision Point (PDP) is the point in the network where decisions about policy are made. This is not to say that the PDP makes the policy – it just enforces them! A PDP can be almost any device in a network, including routers, switches, gateways, and servers. A PDP lets us enable multiple-media applications, WAN efficiency, and alignment of resources to business priorities, just name a few.
Policies are stored in a Policy Repository, which is an LDAP database. These policies are accessed by the PDP (sometimes referred to as a Policy Server). The PDP then distributes the policies to network devices, also referred to as Policy Enforcement Points. Typical policy management functions include:
1. Maximization of current bandwidth usage
2. Mapping network resources for increased performance without bandwidth cost
3. Identifying traffic flows for applications and services
4. Supporting advanced traffic prioritization
5. Administering rules or policies for network behavior
This is not a comprehensive list. There are many more functions of network policies, and I won’t begin to discuss them here. Nearly every corporation with a data or voice network has network policies. Often they are invisible to the end user; sometimes they are put in writing so that users can see them. Network policies are an excellent way to manage network traffic and should almost always be used to ensure Quality of Service.
Network management is also critical to network design. This includes the ability to manage individual devices on the network (with or without being physically present at the device), using fault management techniques, and identifying problems on a proactive basis. Of course, these are not the only things we need to think about when discussing network management, but they are very important. The last one is probably the most important – if we wait for a problem to arise before we fix it, we are asking for trouble. Fixing problems proactively is the key to ensuring network stability.
A Policy Decision Point (PDP) is the point in the network where decisions about policy are made. This is not to say that the PDP makes the policy – it just enforces them! A PDP can be almost any device in a network, including routers, switches, gateways, and servers. A PDP lets us enable multiple-media applications, WAN efficiency, and alignment of resources to business priorities, just name a few.
Policies are stored in a Policy Repository, which is an LDAP database. These policies are accessed by the PDP (sometimes referred to as a Policy Server). The PDP then distributes the policies to network devices, also referred to as Policy Enforcement Points. Typical policy management functions include:
1. Maximization of current bandwidth usage
2. Mapping network resources for increased performance without bandwidth cost
3. Identifying traffic flows for applications and services
4. Supporting advanced traffic prioritization
5. Administering rules or policies for network behavior
This is not a comprehensive list. There are many more functions of network policies, and I won’t begin to discuss them here. Nearly every corporation with a data or voice network has network policies. Often they are invisible to the end user; sometimes they are put in writing so that users can see them. Network policies are an excellent way to manage network traffic and should almost always be used to ensure Quality of Service.
Network management is also critical to network design. This includes the ability to manage individual devices on the network (with or without being physically present at the device), using fault management techniques, and identifying problems on a proactive basis. Of course, these are not the only things we need to think about when discussing network management, but they are very important. The last one is probably the most important – if we wait for a problem to arise before we fix it, we are asking for trouble. Fixing problems proactively is the key to ensuring network stability.
Traffic Flow Design Considerations
Traffic engineering involves the measurement and control of traffic. Main VoIP traffic sources are IP phones and VoIP Trunks. We need to be able to perform traffic engineering on individual nodes and consider the traffic between nodes. Traffic measurement is an analysis of existing traffic flow and the patterns of a network. This will help us to determine how many users and calls a VoIP network can support. Some operational metrics from the system include the number of calls and users, the duration of calls, the number of concurrent calls, call volume profiles, location and call flow, and the number and length of faxes sent and received. In order to assemble this traffic information and make a judgment we need to look at a number of design considerations:
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
Implementing QoS At Layer 3
At Layer 3, Differentiated Services (DiffServ) provides a scalable mechanism for prioritizing packets and providing QoS on a VoIP network. There are three main levels identified by DiffServ. The highest priority level is Expedited Forwarding (EF). Expedited Forwarding packets get priority over all other packets. Assured Forwarding (AF) is the mid-level prioritization. Anything that is not EF or AF is classified as Default, and receives the lowest priority. The DiffServ identifier is found within the DiffServ Code Point (DSCP) found in the header of the IP packet.
DiffServ identifies Per-Hop Behaviors (PHB) for each packet that is sent through. A packet classified as EF will receive the highest priority, and is ideal for low-latency applications such as VoIP. An EF package will almost never be discarded from a DiffServ-capable device.
Assured Forwarding packets are subdivided into three behavior groups – Low Drop, Medium Drop, and High Drop. Each of these groups is further divided into four classes, Class 1, Class 2, Class 3, and Class 4. This gives us a total of twelve AF classifications. The drop precedence of these classifications is often defined by the queuing methods of QoS defined in the previous post. The most common methods are Fair Queuing or Weighted Fair Queuing. The level of forwarding assurance is determined by the load of the AF class and the drop precedence of the packet (in the case of congestion within a class).
A Default (DE) packet is sent using a best-effort behavior. If no DiffServ argument is included in a packet it is assumed to be part of the default category.
There are multiple points where a package can be marked for DiffServ. It can be marked using the end point within the device or application from which it originates, it can be marked using intelligent switches where the device is connected to a network based on its TCP/UDP Port, IP Address, or VLAN. The packet can be marked at a core or edge router where the packet encounters links. Traffic entering a network is classified, and possibly conditioned, at the boundaries of the network and is assigned to different behavior aggregates identified by a single DSCP. DiffServ edge router and switch interfaces can be configured to trust or distrust previously marked DSCP or 802.1p tagged packets. If the packet is trusted, the DSCP tag will remain the same. If it is distrusted, the DiffServ router will assign a new DSCP tag.
There are three types of nodes on a DiffServ domain: Edge nodes, Boundary Nodes, and Interior Nodes. The Edge node is the first IP Aware device that applies QoS policies. Edge Nodes and Boundary Nodes are configured to trust or distrust the DSCP identification and forward the packets from one node to another.
DiffServ identifies Per-Hop Behaviors (PHB) for each packet that is sent through. A packet classified as EF will receive the highest priority, and is ideal for low-latency applications such as VoIP. An EF package will almost never be discarded from a DiffServ-capable device.
Assured Forwarding packets are subdivided into three behavior groups – Low Drop, Medium Drop, and High Drop. Each of these groups is further divided into four classes, Class 1, Class 2, Class 3, and Class 4. This gives us a total of twelve AF classifications. The drop precedence of these classifications is often defined by the queuing methods of QoS defined in the previous post. The most common methods are Fair Queuing or Weighted Fair Queuing. The level of forwarding assurance is determined by the load of the AF class and the drop precedence of the packet (in the case of congestion within a class).
A Default (DE) packet is sent using a best-effort behavior. If no DiffServ argument is included in a packet it is assumed to be part of the default category.
There are multiple points where a package can be marked for DiffServ. It can be marked using the end point within the device or application from which it originates, it can be marked using intelligent switches where the device is connected to a network based on its TCP/UDP Port, IP Address, or VLAN. The packet can be marked at a core or edge router where the packet encounters links. Traffic entering a network is classified, and possibly conditioned, at the boundaries of the network and is assigned to different behavior aggregates identified by a single DSCP. DiffServ edge router and switch interfaces can be configured to trust or distrust previously marked DSCP or 802.1p tagged packets. If the packet is trusted, the DSCP tag will remain the same. If it is distrusted, the DiffServ router will assign a new DSCP tag.
There are three types of nodes on a DiffServ domain: Edge nodes, Boundary Nodes, and Interior Nodes. The Edge node is the first IP Aware device that applies QoS policies. Edge Nodes and Boundary Nodes are configured to trust or distrust the DSCP identification and forward the packets from one node to another.
Quality of Service
As I have mentioned before, packets are transmitted from one end and recompiled at the destination. Not all packets will necessarily take the same path to their destination, which means that they may not all arrive in the same order they were sent in. We can also experience packet loss. In a data network, if a packet is lost or discarded, it is simply re-sent. In a VoIP environment this is not an option. All packets are time-critical and must be received in a timely fashion. We can’t wait for a packet to be re-sent! Quality of Services tries to ensure that time-sensitive packets are given priority over data packets. Other considerations include the amount of packet overhead and the size of the packets. A smaller packet size is more tolerant to packet loss, but every packet has a fixed amount of overhead. For Ethernet, this is 40 bytes. Packet size must be considered when we calculate the bandwidth requirements for our network.
There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.
A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.
Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:
Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality
Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:
Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)
Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.
Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.
There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.
A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.
Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:
Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality
Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:
Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)
Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.
Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.
Recognizing QoE Problems on the User’s Side
Most IP networks use a best-effort delivery system and treat all IP packets equally. Traffic can experience different amounts of packet delay, loss, or jitter at any time. With data applications this isn’t an issue, and just affects the speed of transmission. With VoIP networks this does become an issue, however, as VoIP is a real-time protocol.
Speech breakup may be perceived by the user as distorted, like the signal on a digital cellular telephone when the user is getting out of range. Speech clipping seems like parts of words are getting cut off. When the user complains about pops and clicks on the line it usually means that there are dropped packets. Echo means that the user hears their own voice reflected back to them from the other end. These symptoms have all been addressed in previous posts.
Speech breakup may be perceived by the user as distorted, like the signal on a digital cellular telephone when the user is getting out of range. Speech clipping seems like parts of words are getting cut off. When the user complains about pops and clicks on the line it usually means that there are dropped packets. Echo means that the user hears their own voice reflected back to them from the other end. These symptoms have all been addressed in previous posts.
CODECs
There are four main CODECs used in VoIP. These are G.711, G.729a/b, G.726, and G.723.1.
G.711 is a 64kbps PCM encoding. It uses the most bandwidth and does not offer any compression. It has the best voice quality, as voice signals are transmitted without any loss due to compression. It is also the most fault-tolerant CODEC. If one packet is lost, it will not represent any noticeable amount of disruption to the conversation, as it does not contain a lot of voice data. G.711 has the least processing delay of any CODEC as it does not have to compress the samples, simply sending them along the network uncompressed. This is only recommended for high-speed (100Mbps) LAN implementations, as it does require a great deal of bandwidth. Attempting to transmit G.711 across low-bandwidth pipes will result in undesired jitter.
G.726 can compress data down to 40, 32, 24, or 16 kbps. It uses ADPCM encoding which works by looking at the difference between the previous sample and the current sample, and only sending the difference. It uses less bandwidth than G.711, but sacrifices voice quality.
G.729a/b is able to compress data down to an 8kbps stream. It uses CS-ACELP encoding which works by matching sound patterns in the voice sample to a codebook. It then sends the code (not the sample) across the network, where the receiving end looks up the code and reproduces the sound based on the code. G.729 has near-toll quality sound, meaning that it is almost as good as using an analog phone. It also uses a technology called silence suppression to further increase bandwidth savings. Silence suppression is quite simple – in any conversation there is usually only one end talking, so half of the bandwidth would be zero noise. To deal with this, G.729 sends a silence signal to the other end, which plays a white noise to indicate that there is no voice coming from the other end. G.729 offers the best balance of quality and bandwidth savings, and is the most commonly implemented CODEC in VoIP.
G.723.1 is a standard that covers two encoding rates. It can operate at 5.38kbps using CS-ACELP encoding, much like G.729. It can also operate at 6.4 kbps using MPMLQ encoding. MPMLQ also uses a codebook to translate voice signals into data, but uses a different compression scheme. G.723.1 has the lowest bandwidth requirements, but at the same time has the lowest voice quality of the different CODECs.
So that is a summary of the different CODECs used for VoIP. G.711 is the CODEC of choice when bandwidth is not an issue, and G.729 is the CODEC of choice when bandwidth is an issue.
It should also be noted that transcoding may occur from one CODEC to another as the voice signal is carried across the network. For example, internal communications on the high-speed LAN may be in G.711, but the signal may need to be transmitted at a higher compression rate using G.729 when it is sent across the WAN. When transcoding occurs, there is additional delay caused while the signal is converted. As such, it is generally a good idea to use one CODEC for the entire network. As such, it is recommended to use the most optimal CODEC for ALL parts of the network, not for each segment.
G.711 is a 64kbps PCM encoding. It uses the most bandwidth and does not offer any compression. It has the best voice quality, as voice signals are transmitted without any loss due to compression. It is also the most fault-tolerant CODEC. If one packet is lost, it will not represent any noticeable amount of disruption to the conversation, as it does not contain a lot of voice data. G.711 has the least processing delay of any CODEC as it does not have to compress the samples, simply sending them along the network uncompressed. This is only recommended for high-speed (100Mbps) LAN implementations, as it does require a great deal of bandwidth. Attempting to transmit G.711 across low-bandwidth pipes will result in undesired jitter.
G.726 can compress data down to 40, 32, 24, or 16 kbps. It uses ADPCM encoding which works by looking at the difference between the previous sample and the current sample, and only sending the difference. It uses less bandwidth than G.711, but sacrifices voice quality.
G.729a/b is able to compress data down to an 8kbps stream. It uses CS-ACELP encoding which works by matching sound patterns in the voice sample to a codebook. It then sends the code (not the sample) across the network, where the receiving end looks up the code and reproduces the sound based on the code. G.729 has near-toll quality sound, meaning that it is almost as good as using an analog phone. It also uses a technology called silence suppression to further increase bandwidth savings. Silence suppression is quite simple – in any conversation there is usually only one end talking, so half of the bandwidth would be zero noise. To deal with this, G.729 sends a silence signal to the other end, which plays a white noise to indicate that there is no voice coming from the other end. G.729 offers the best balance of quality and bandwidth savings, and is the most commonly implemented CODEC in VoIP.
G.723.1 is a standard that covers two encoding rates. It can operate at 5.38kbps using CS-ACELP encoding, much like G.729. It can also operate at 6.4 kbps using MPMLQ encoding. MPMLQ also uses a codebook to translate voice signals into data, but uses a different compression scheme. G.723.1 has the lowest bandwidth requirements, but at the same time has the lowest voice quality of the different CODECs.
So that is a summary of the different CODECs used for VoIP. G.711 is the CODEC of choice when bandwidth is not an issue, and G.729 is the CODEC of choice when bandwidth is an issue.
It should also be noted that transcoding may occur from one CODEC to another as the voice signal is carried across the network. For example, internal communications on the high-speed LAN may be in G.711, but the signal may need to be transmitted at a higher compression rate using G.729 when it is sent across the WAN. When transcoding occurs, there is additional delay caused while the signal is converted. As such, it is generally a good idea to use one CODEC for the entire network. As such, it is recommended to use the most optimal CODEC for ALL parts of the network, not for each segment.
VoIP Network Design Considerations
Combining voice and data on a single network offers much efficiency in terms of cost. There are a number of considerations, however, when implementing real-time solutions like VoIP. A real measure of the performance of a VoIP network is the Quality of Experience (QoE). This is a subjective measurement of a user’s perception of the quality of calls. The user’s perception can be affected by things such as the CODEC used, sound fidelity, end-to-end delay, packet loss, jitter, and echo.
The clarity of the voice signal is dependent on the performance of the CODEC and the rate of lost and discarded packets. I will discuss CODECs at great length later, so for now I will focus on packet loss.
There are two types of packet loss in a VoIP environment: True Network Packet Loss and Jitter Buffer Discard Loss. True network packet loss occurs when a packet that is being sent across the network does not reach its destination. This can be as a result of data corruption, as each packet is checked by each switch and router to ensure that it is still intact. If the packet has become corrupted the switch will drop the packet. Other causes of packet loss can be switch congestion (too many packets are being sent across the switch and some are dropped to ensure that others are delivered) or a duplex mismatch occurs. In a data network this will be automatically corrected by the system receiving the data. If a packet is dropped in a data network the receiving system will ask the sending system to forward that packet again. In a VoIP environment, however, we do not have the time to wait for anything to be retransmitted. Due to the small amount of voice data in these packets, a VoIP implementation will be able to handle the loss of some packets with minimal impact. Quite often the loss of even more than one packet is not noticed by the end user. Jitter Buffer loss is a bit more complex than just having packets go missing. Jitter occurs when packets are received out of order. To avoid this problem, most VoIP implementations use a jitter buffer, which allows the data to be re-assembled in the correct order at the receiving end. Packets are not always received in order due to the nature of the IP network. Since it is connectionless, packets follow the best route they can find to their destination end-point. Each packet is independent of the other packets and may take a different route, depending on network conditions and a number of other factors. Jitter buffer loss occurs when a voice packet is delayed beyond an acceptable limit as defined by the jitter buffer. There are a number of reasons we can see jitter occurring, such as serialization delay (when packets are stuck behind large data frames waiting to be transmitted over slow links), or when frame relay circuits are oversubscribed. Another common cause of jitter is having half-duplex links in the media path.
A third issue that affects VoIP QoE is echo. Echo occurs when there is an audible leak-through of your own voice into the receive path or the send path. This is usually caused by an impedence mismatch in the 2-wire or 4-wire connection on either end. The amount of time for a round trip of the voice affects the amount of echo. The rule of thumb is 10 ms or less and there is no noticeable echo. From 10-30 ms, the users may notice a hollow sound to the voice. Above 30 ms there is a noticeable echo. Echo is a big problem when converting from PSTN to VoIP. Echo cancellers in the PSTN suppress the echo amplitude so it can’t be heard. Because VoIP uses a built-in delay the echo may be noticeable. Techniques to control echo include a properly designed loss plan to minimize the returned signal, echo suppression which is designed to remove echo, and ECANs which calculate an estimate of what the echo will be and then subtract that from the actual returned signal.
The clarity of the voice signal is dependent on the performance of the CODEC and the rate of lost and discarded packets. I will discuss CODECs at great length later, so for now I will focus on packet loss.
There are two types of packet loss in a VoIP environment: True Network Packet Loss and Jitter Buffer Discard Loss. True network packet loss occurs when a packet that is being sent across the network does not reach its destination. This can be as a result of data corruption, as each packet is checked by each switch and router to ensure that it is still intact. If the packet has become corrupted the switch will drop the packet. Other causes of packet loss can be switch congestion (too many packets are being sent across the switch and some are dropped to ensure that others are delivered) or a duplex mismatch occurs. In a data network this will be automatically corrected by the system receiving the data. If a packet is dropped in a data network the receiving system will ask the sending system to forward that packet again. In a VoIP environment, however, we do not have the time to wait for anything to be retransmitted. Due to the small amount of voice data in these packets, a VoIP implementation will be able to handle the loss of some packets with minimal impact. Quite often the loss of even more than one packet is not noticed by the end user. Jitter Buffer loss is a bit more complex than just having packets go missing. Jitter occurs when packets are received out of order. To avoid this problem, most VoIP implementations use a jitter buffer, which allows the data to be re-assembled in the correct order at the receiving end. Packets are not always received in order due to the nature of the IP network. Since it is connectionless, packets follow the best route they can find to their destination end-point. Each packet is independent of the other packets and may take a different route, depending on network conditions and a number of other factors. Jitter buffer loss occurs when a voice packet is delayed beyond an acceptable limit as defined by the jitter buffer. There are a number of reasons we can see jitter occurring, such as serialization delay (when packets are stuck behind large data frames waiting to be transmitted over slow links), or when frame relay circuits are oversubscribed. Another common cause of jitter is having half-duplex links in the media path.
A third issue that affects VoIP QoE is echo. Echo occurs when there is an audible leak-through of your own voice into the receive path or the send path. This is usually caused by an impedence mismatch in the 2-wire or 4-wire connection on either end. The amount of time for a round trip of the voice affects the amount of echo. The rule of thumb is 10 ms or less and there is no noticeable echo. From 10-30 ms, the users may notice a hollow sound to the voice. Above 30 ms there is a noticeable echo. Echo is a big problem when converting from PSTN to VoIP. Echo cancellers in the PSTN suppress the echo amplitude so it can’t be heard. Because VoIP uses a built-in delay the echo may be noticeable. Techniques to control echo include a properly designed loss plan to minimize the returned signal, echo suppression which is designed to remove echo, and ECANs which calculate an estimate of what the echo will be and then subtract that from the actual returned signal.
Gauging the Viability of a Customer’s Existing Network
To add VoIP to an existing data network, we must first evaluate the architecture of the network to determine if it will support the addition of voice traffic. If we are able to determine that the network is not capable of handling voice traffic we will need to identify the steps that must be taken to provide this functionality.
When analyzing a customer’s network we need to ask the following questions:
1. Is the customer using half-duplex or full-duplex Ethernet connections?
2. Has the customer enabled or implemented auto-negotiation?
3. Does the customer’s network provide reliable, continuous power?
4. Does the customer use Layer 2 or Layer 3 switches, or is the customer using shared media (such as a hub)?
5. Is the customer implementing the best protocols and applications for their particular situation?
In a VoIP network both sides must support auto-negotiation. Auto-negotiation is the automatic recognition of the functions of the system or device connected to the other end of has, so that devices are able to configure themselves automatically to work with the receiving components. If we do not have full-duplex auto-negotiation at both ends of a connection we will experience call clipping. Some devices, such as hubs, do not support auto-negotiation. If we do not have auto-negotiation enabled we can also have device mismatches occurring.
It is important to build power management into your VoIP network. We need to ensure that redundant power supplies are used for network equipment to ensure a continuous supply of power to the network devices in the event of a power failure. This may include Universal Power Supplies and backup generators. We must also ensure that we have sufficient cooling in our wiring closets so that devices do not overheat. In addition to providing reliability of our backbone equipment, many IP terminals are able to draw power from the network cabling referred to as Power over Ethernet (PoE) or Power over LAN (PoL). Using PoE eliminates the need to plug sets into an AC power source. The devices draw power from unused lines in the Cat5 cable to provide power to the connected device. PoE functionality is included in many modern layer 2 switches, including the Baystack 400 switches from Nortel.
We also need to look at the switching method implemented in the network. Shared media, such as hubs, simply rebroadcast all signals to all ports. This can cause increased network traffic and lead to packet collisions. At a minimum, Layer 2 switches must be used. Layer 3 switches (switches that include routing capabilities) may also be used in VoIP network. Hubs should never be used in a VoIP implementation. A Layer 2 switch operates by identifying the MAC address of the receiving machine and directs the packets accordingly. A Layer 3 switch stores routing information in hardware based on IP information, and can dynamically update the routing paths based on availability of paths. Using a Layer 3 switch can reduce packet latency.
We also need to consider the protocols that are being used on the network. Some protocols require very little bandwidth (such as SNMP and NTP), and are of little concern. Other applications, such as HTTP and SMTP can use a greater amount of bandwidth. We need to take this into consideration when adding VoIP to an existing or new network. Some protocols, such as SQL, use a very large amount of bandwidth. Systems that are running these protocols should be located on their own LAN or VLAN.
When planning a VoIP installation we should follow these steps:
1. Obtain or create diagrams for existing LAN/WAN infrastructure
2. Identify physical and logical locations of important networking equipment
3. Document types and lengths of physical cables and circuits
4. Analyze infrastructure and identify any problematic conditions that might arise in the future – we must then determine if our client’s business and technical goals are realistic
When analyzing a customer’s network we need to ask the following questions:
1. Is the customer using half-duplex or full-duplex Ethernet connections?
2. Has the customer enabled or implemented auto-negotiation?
3. Does the customer’s network provide reliable, continuous power?
4. Does the customer use Layer 2 or Layer 3 switches, or is the customer using shared media (such as a hub)?
5. Is the customer implementing the best protocols and applications for their particular situation?
In a VoIP network both sides must support auto-negotiation. Auto-negotiation is the automatic recognition of the functions of the system or device connected to the other end of has, so that devices are able to configure themselves automatically to work with the receiving components. If we do not have full-duplex auto-negotiation at both ends of a connection we will experience call clipping. Some devices, such as hubs, do not support auto-negotiation. If we do not have auto-negotiation enabled we can also have device mismatches occurring.
It is important to build power management into your VoIP network. We need to ensure that redundant power supplies are used for network equipment to ensure a continuous supply of power to the network devices in the event of a power failure. This may include Universal Power Supplies and backup generators. We must also ensure that we have sufficient cooling in our wiring closets so that devices do not overheat. In addition to providing reliability of our backbone equipment, many IP terminals are able to draw power from the network cabling referred to as Power over Ethernet (PoE) or Power over LAN (PoL). Using PoE eliminates the need to plug sets into an AC power source. The devices draw power from unused lines in the Cat5 cable to provide power to the connected device. PoE functionality is included in many modern layer 2 switches, including the Baystack 400 switches from Nortel.
We also need to look at the switching method implemented in the network. Shared media, such as hubs, simply rebroadcast all signals to all ports. This can cause increased network traffic and lead to packet collisions. At a minimum, Layer 2 switches must be used. Layer 3 switches (switches that include routing capabilities) may also be used in VoIP network. Hubs should never be used in a VoIP implementation. A Layer 2 switch operates by identifying the MAC address of the receiving machine and directs the packets accordingly. A Layer 3 switch stores routing information in hardware based on IP information, and can dynamically update the routing paths based on availability of paths. Using a Layer 3 switch can reduce packet latency.
We also need to consider the protocols that are being used on the network. Some protocols require very little bandwidth (such as SNMP and NTP), and are of little concern. Other applications, such as HTTP and SMTP can use a greater amount of bandwidth. We need to take this into consideration when adding VoIP to an existing or new network. Some protocols, such as SQL, use a very large amount of bandwidth. Systems that are running these protocols should be located on their own LAN or VLAN.
When planning a VoIP installation we should follow these steps:
1. Obtain or create diagrams for existing LAN/WAN infrastructure
2. Identify physical and logical locations of important networking equipment
3. Document types and lengths of physical cables and circuits
4. Analyze infrastructure and identify any problematic conditions that might arise in the future – we must then determine if our client’s business and technical goals are realistic
VOIP Technologies
VoIP calls convert conversations into data packets which require a higher Quality of Service (QoS) and require security measures for Local Area Networks, Wide Area Networks, and Wireless Networks.
Signaling protocols and standards stipulate how networking equipment initiates and controls the flow of voice, video, and data communications. There are two major signaling protocol standards: H.323 and SIP.
H.323 is a suite of protocols that provides a foundation for audio, video, and data communications across IP-Based networks, including the Internet. H.323 is platform-, network-, and application-independent. It was created by the International Telecommunications Union (ITU), published in 1996. The current iteration of H.323 was published in 2006.
SIP stands for Session Initiation Protocol, and is a protocol that allows IP-Capable endpoints to create media sessions, such as telephone calls and video calls, with each other. SIP was developed by the Internet Engineering Task Force (IETF). SIP was originally started in 1996, and has evolved over the years into the current iteration. The initial SIP protocol was defined by RFC 2543, and the current version has been defined under RFC 3261. SIP is defined as a method of communication between multiple IP-based multimedia devices. SIP uses the Real-Time Transport Protocol (RTP) and the Session Description Protocol (SDP) to make communications possible between end-points. RTP transports the information, whether that is voice, video, or data. SDP is used to establish the session and session parameters. SIP is an Application-Layer protocol, and as such it allows for a variety of different applications, including voice, video, and gaming. SIP can work on IPv4 and IPv6 networks.
H.323
H.323 is comprised of six main components:
1. Media Gateway
2. H.323 Gateway
3. Call Servers
4. Gatekeepers
5. IP Terminals
6. IP Backbone Network
Starting at the top of the list, the Media Gateway converts one media stream into another. It can interact with call controllers, proxies, and soft switches using proprietary or standard protocols. It converts digital packets to analog and vice versa. It is the connecting point between the PSTN and the IP network.
The H.323 gateway transforms audio received from a telecommunications system into a format that the data network can use. It acts as a bridge to IP networks from voice networks and has built-in intelligence to select voice compression CODECs. It adjusts protocols and timing between two dissimilar computer systems, or voice-over-data networks. It performs the same functions as a media gateway.
A Call Server is responsible for helping to set up the calls on the data network. It receives call set-up request messages, determines the status of destination devices, and checks the authorization of users to originate or receive calls. The Call Server also creates and sends the necessary messages to process call requests.
A Gatekeeper provides call control, media access, and bandwidth management between endpoints. The Gatekeeper performs address translation, admissions control, and zone control. It will co-ordinate access to other servers and manage call routing. The Gatekeeper maps the destination telephone numbers to their destination end-point IP addresses. They can select the correct CODEC and translate between H.323 and other protocols. The Gatekeeper is the node that provides call control. In addition, the Gatekeeper can be used for a number of other functions, including dialing plans, call accounting, and many more. Gatekeepers can control the number of simultaneous calls, as well as the number of H.323 devices that can be supported on the network. The Gatekeeper is also responsible for managing all different zones.
IP Terminals and Clients are any end-point on the IP network. These can be hard phones or soft phones, as well as wireless devices. Basically, anything that brings voice and data communication to the end user.
The IP Backbone Network is the network on which the H.323 system is running. It must be IP-based. The number of devices that can be supported is partially defined by the bandwidth of this network. An IP network can be both wired and wireless. The IP network allows for dissimilar networks and systems to communicate and inter-connect.
H.323 is not as widely used as SIP. SIP offers greater flexibility than H.323 and is quickly eclipsing H.323 as the dominant protocol for VoIP traffic. SIP can inter-operate with H.323 networks through a SIP gateway. A SIP Gateway will sit at the edge of the SIP domain and translate what goes on inside the SIP domain into whatever the outside network needs (i.e. H.323 or PSTN, etc.). A SIP Gateway has two basic functions: translating the signaling stream and translating the media stream.
Subscribe to:
Posts (Atom)