Showing posts with label RTP. Show all posts
Showing posts with label RTP. Show all posts

Thursday

The Basics of Telephony

Because Unified Messaging must be integrated into your company's telephony solution, it's important to understand the most crucial terms and definitions to be able to follow.
Note 
If your company is already connected to Office Communications Server 2007 or later with your telephone system, you don't need to consider the details in the following sections; Exchange 2010 will use OCS as the gateway.

Types of Telephone Systems

Three general types of business telephone systems can be integrated with Unified Messaging:
  • Centrex Phone System Phone companies lease a Centrex phone system (also known as Central Office Telephone Exchange) to businesses. The Centrex phone system uses the phone company's central office (CO) exchange to route internal calls to an extension. A new Centrex version called IP Centrex is available. With IP Centrex, the organization does not rent phone lines from the telephone company's CO. Instead, the CO sends the phone calls through a VoIP gateway, which routes them over a VoIP gateway or through the Internet. At the organization's office, another VoIP gateway translates the call to a traditional circuit-switched call.

  • Key Telephone System This phone system is similar to the Centrex system in that the organization leases several phone lines from the telephone company. However, with the Key Telephone System, each phone line connects to multiple telephones in the organization. When someone calls the company, all phones ring that are associated with that line. Businesses with Key Telephone Systems often arrange for someone to answer incoming calls, and then announce the call to the correct recipient.
    Note 
    Some key telephone systems can work with UM if an IP gateway is added. However, some less sophisticated systems may not work even if a supported IP gateway is used. Make sure you contact your vendor before you try to use your key telephone system with Exchange 2010.

  • Private Branch Exchange System A Private Branch Exchange (PBX) system is different from the other telephone systems in that it typically has only a single connection to the phone company and all call switching happens at the organization. The connection to the phone company usually occurs through a T1 or E1 line, both of which provide multiple channels to enable multiple calls over the same line, also called trunk lines. The PBX routes internal phone calls and those between external and internal users. In a PBX system, each user has a telephone extension. When an internal user places a call to another internal user, she uses only the extension number, and the PBX routes the call to the appropriate extension.

Types of PBX

PBX systems are the most common telephone system type that medium- and large-size organizations use. Several types of PBX systems are available:
  • Analog PBX Analog PBX systems send voice and signaling information, such as the touch tones of dialed phone numbers, as actual analog sound. Analog PBX systems never digitize the sound. To direct the call, the PBX and the phone company's CO listens for the signaling information.

  • Digital PBX Digital PBXs encode analog sound into a digital format. They typically encode the voice using a standard industry audio codec, G.711. After digital PBXs encode the sound, they send the digitized voice on a channel using circuit switching. The process of circuit switching establishes an end-to-end open connection, and leaves the channel open for the call's duration and for the call's users only. Some PBX manufacturers have proprietary signaling methods for call setup, such as Avaya Definity G3si PBX.

  • IP PBX IP PBXs include a Network Interface Card (NIC) to provide voice over regular network. The phone converts voice into digitized packets, which it then transfers over the network. The network sends the voice packets via packet switching, a technique that enables a single network channel to handle multiple calls. The IP PBX also acts as a gateway between the internal packet-switched network and the external circuit-switched networks that phone company's use. In this situation, external phone calls arrive at the IP PBX on the normal public phone lines, and the IP PBX converts the phone call to packets sent on the internal IP-based network. An example of this is Cisco Call Manager.

  • Hybrid PBX Hybrid PBXs provide both digital and IP PBX capabilities. This hybrid approach enables a customer to run a mixture of digital and IP-based phones. Most modern PBXs are in this hybrid category, such as SEN HiPath 4000.

VoIP Gateway Introduction


A VoIP gateway is a third-party hardware device or product that converts traditional phone-system or circuit-switching protocols into data-networking or packet-switched protocols. The VoIP gateway connects a telephone network with a data network.

Unified Messaging servers can connect only to packet-switched data networks. This means that organizations with a traditional PBX must deploy a VoIP gateway to communicate between the PBX and the Unified Messaging server.

Unified Messaging Protocols

There are a number of voice-related, IP-based protocols. A Unified Messaging environment with Exchange Server 2010 uses the following:
  • Session Initiation Protocol (SIP) SIP is a real-time signaling protocol that creates, manipulates, and disconnects interactive communication sessions on an IP network. The UM role uses SIP mapped over Transmission Control Protocol (TCP) and supports TLS for secured SIP environments. SIP clients, such as IP/VoIP gateways and IP/PBXs, can use TCP port 5060 or port 5061 (for Secure SIP) to connect to UM server roles. You can find more information about the SIP protocol at http://tools.ietf.org/html/rfc3261.

  • Real-time Transport Protocol (RTP ) RTP is for voice transport between the IP gateway and the Unified Messaging server. RTP provides high-quality, real-time, streaming voice delivery. One of the issues with sending voice messages over an IP network is that voice requires real-time transport with specific quality requirements to ensure that the voice sounds normal. If the protocol uses large packets, listeners must wait for the entire packet to arrive before they can respond. Any delay in packet delivery can produce undesirable periods of midstream silence. Packet loss can cause voice garbling. You can get more information about the RTP protocol at http://tools.ietf.org/html/rfc3550.

Sunday

Real-Time Transport Protocol | VoIP Standards and Specifications

The RTP provides end-to-end network transport functions suitable for applications transmitting real-time audio or video packets over multicast or unicast network services. It was developed by the IETF and is used with the H.323’s recommended H.225 protocols to provide reliable communications. RTP by itself does not address resource reservation and does not guarantee QoS for real-time services. The packet transport is supplemented by a control protocol (RTCP) that monitors data delivery in a manner scalable to large multicast networks and provides minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. The following are the elements of RTP.

RTP Payload

The media payload is transported by RTP in a packet, such as audio samples or compressed video data. The payload format and interpretation are beyond the scope of this document.

RTP Packet

A packet consists of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically, one packet of the underlying protocol contains a single RTP packet, but several RTP packets may be contained, if permitted by the encapsulation method.

RTCP Packet

A control packet consists of a fixed header part similar to that of RTP packets, followed by structured elements that depend on the RTCP packet type. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet. Figure 1 shows the RTP header.


Figure 1: The RTP header.

The RTP fixed header fields have certain functions. V (version): Identifies the RTP version. P (padding): When set, the packet contains one or more additional padding octets at the end that are not part of the payload. X (extension bit): When set, the fixed header is followed by exactly one header extension with a defined format. CSRC count: Contains the number of CSRC identifiers that follow the fixed header. M (marker): The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. Payload type: Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means. Sequence number: Increments by one for each RTP data packet sent and may be used by the receiver to detect packet loss and restore packet sequence. Timestamp: Reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). SSRC (synchronization source): Identifies the synchronization source. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. CSRC (contributing source): Contributing source identifiers list. Identifies the contributing sources for the payload contained in this packet.

Thursday

The Need for RTP/RTCP

The IP is a relatively low-level protocol. It was originally developed for delivery of packets (or datagrams) between host computers across the ARPAnet (Internet) packet network. For an IP telephony application, datagrams are transmitted between desktop voice terminals. IP is a connectionless protocol that does not establish a virtual connection through a network before commencing transmission. Establishing a communications path between endpoints is the responsibility of higherlevel protocols.

IP makes no guarantees concerning reliability, flow control, error detection, or error correction. As a result, datagrams could arrive at the destination computer out of sequence, with errors, or not even arrive at all. This is known as jitter. IP does succeed in making the network transparent to the upper layers involved in voice transmission through an IPbased network.

VoIP transmission, by definition, uses IP, although it is not well suited for voice transmission. Real-time applications such as voice and video require guaranteed connection with consistent delay characteristics. Higher-layer protocols address these issues. There are two available protocols at the transport layer when transmitting information through an IP network. These are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Both protocols enable the transmission of information between the correct processes (or applications) on network endpoints. These processes are associated with unique port numbers.

TCP is a connection-oriented protocol. It establishes a communications path before transmitting data. It handles sequencing and error detection, thus ensuring that a reliable stream of data is received by the destination application. TCP can address real-time voice applications to a certain extent but would require higher-layer functions. Voice applications require that information is received in the correct sequence, reliably, and with predictable delay characteristics. With this in mind, the ITU-T decided that the alternative protocol, UDP, should be used. UDP is also a connectionless protocol. UDP routes data to its correct destination port but does not attempt to perform any sequencing or ensure data reliability.

To provide feedback on the quality of the transmission link, the RTP/RFTP protocols, developed by the IETF, are used. Real-Time Transport Protocol (RTP) transports the digitized samples of real-time information, and Real-Time Control Protocol (RTCP) provides the mechanism for quality feedback. RTP and RTCP do not reduce the overall delay of the real-time information. Nor do they make any guarantees concerning QoS.

When an IP voice terminal transmits datagrams across the LAN/WAN, the IP, UDP, and RTP headers are followed by the data payload of the RTP header. The data payload is comprised of digitized voice samples. The length of these samples can vary, but for voice samples representing 20 ms are considered the maximum duration for the payload. The number of transmitted datagrams varies indirectly with the sampling rate—the longer the sampling period, the fewer the number of packets transmitted per second. The selection of the payload duration is a compromise between bandwidth requirements and quality. Smaller payloads demand higher bandwidth per channel band because the header length remains at 40 octets. However, if payloads are increased, the overall delay of the system will increase, and the system will be more susceptible to the loss of individual packets by the network.

Related Posts with Thumbnails

Link Exchange