ICE L9 VoIP 004

Internet Communication Engineering
23/07/2010
Presentation Outline Voice over IP

Mark A Gregory RMIT University 10.8.6 0418 999 089 mark.gregory@rmit.edu.au
Brief overview of VoIP and applications Challenges of VoIP IP Support for Voice Protocols used for VoIP (current views)
RTP RSVP SIP
1 July 2006
RTCP H.323
Copyright RMIT University
Objectives
Understand the current state of the art in Internet Telephony. Describe the key protocols involved in VoIP and their roles in this new technology. Discuss the limitations of current VoIP technology. Identify key factors influencing the growth of Internet telephony services for global communications.
1 July 2006 Copyright RMIT University 3
References
Internet RFCs
RFC1889 - RTP RFC 2205 - 2209 - RSVP
ITU-T
H.323 - Packet-based multimedia communications systems
Voice over IP - Technology Guide Series IEEE Network May/June 1999

Introduction
Many companies have seen advantages in minimising costs by transporting voice over IP networks. This has set the stage for standards development and the design of terminals and gateways and the rolling out of services on a global scale. Reliability Quality
Introduction
Adding voice to packet networks generates many challenges:
interoperability packet loss delay scalability
1 July 2006
1 July 2006
23/07/2010
Examples of Possible VoIP Applications

PSTN Gateways
PC based telephone accessing a public network by calling a gateway at a point close to the destination to minimise long distance charges.
Internet aware telephones

Enhancement of ordinary telephones to serve as an Internet access device as well as ordinary telephony. Directory services could be accomplished via the Internet.
1 July 2006
1 July 2006
1 July 2006
1 July 2006
10
Examples of Possible VoIP Applications

Tie line replacement
Intranet links could replace tie lines between company PBXs
More on Challenges
Voice quality has to be comparable to PSTN Underlying network must meet strict performance criteria including:
minimising call rejections network latency packet loss disconnects
Remote access from branch or home

Small office could gain access to corporate voice, data and fax.
Voice calls from a mobile PC via the Internet Internet call centres
1 July 2006
12
23/07/2010
More on Challenges
Call control (signalling) must make the telephone calling process transparent so that the callers need not know the technology involved. PSTN / VoIP service interworking. System management and security and accounting and consolidated with PSTN Operation Sub Systems
End to End Delay for VoIP PC Phone Call

Delay (End to End) Round trip
PSTN
Telephone Client PSTN
IP
Gateway
PSTN
Access
HE L TT WE P KA AC RD
Vectra Office
PC Client
Above chart from IEEE Network May/June 1999 Author Bill Goodman Internet Telephony and Modem Delay
IP Network Support for Voice

We need a network that is capable of supporting real time telephone and fax.

Three techniques for improving network QoS:
Controlled networking environment
Capacity pre-planned and adequate performance
Management tools
to configure network nodes, monitor performance, and manage capacity and flow on a dynamic basis.
Control protocols and mechanisms

Protocols such as RSVP (Resources Reservation Protocol) and RTP (Real Time Protocol)
1 July 2006 Copyright RMIT University 15 1 July 2006 Copyright RMIT University 16

Real time voice traffic can be carried over IP networks in 3 ways:
Voice trunks
Voice packets are transferred between pre-defined IP addresses Eliminate the need for phone number conversions. Fall back to the PSTN as an option.

Telephony
Appears like normal phone but employs various forms of voice over packet networks. Gateway functionality is required if the PSTN needs to be accessed.
PC to PC Voice
Multimedia PCs can utilise this technique without connecting to the PSTN. System emulates an Internet Chat group and can be combined with multimedia whiteboards.
23/07/2010

IP Network Protocols currently being used to implement VoIP:
H.323 SIP RTP, RSVP, RTCP UDP/TCP Network Layer (IPv4 and IPv6) Data Link Layer Physical Layer
RTP - Real-time Transport Protocol

Reference: RFC 1889 A real time end to end protocol
Utilises existing transport layers for data that has real time properties. Used by H.323 Takes the bitstream generated by the media encoder breaking it into packets, sending the packets over the network and recovering the bitstream at the receiver.
19 1 July 2006 Copyright RMIT University 20
We shall look at SIP, RTP, RTCP and RSVP to see their functions. This will be followed by a brief overview of H.323.
1 July 2006

Plays a key role in Internet telephony since it is the component that moves the actual voice among the participants. Signalling protocols provide the parameters for RTP transport.

Specific functions provided by RTP are:
Sequencing
Each RTP pack has a sequence number used for loss detection and compensation for reordering.
Intramedia synchronisation
Packets within the same stream can suffer different delays (jitter). Applications use playout buffers to compensate for this jitter. RTP provides timestamps to assist in this.
1 July 2006
21
1 July 2006
22

Payload Identification
Since network conditions may vary during a call, it may be necessary to change encoding dynamically. RTP contains a payload type identifier in each packet.

Source Identification
In a multicast session, many users are participating and so there has to be a mechanism for a packet to say which participant actually sent it. A special identifier called a SSRC - Synchronisation Source is included in the protocol.
Frame Indication
Video and audio are sent in logical units called frames. It is used to mark B of Frame and E of Frame for upper layers.
1 July 2006
23
The RTP protocol has a companion protocol called the Real Time Control Protocol (RTCP).
1 July 2006 Copyright RMIT University
24
23/07/2010

RTP does NOT:
guarantee real-time delivery of data. prevent out-of-order delivery. Assume that the underlying network is reliable.
RTP Header
The RTP Header provides the timing information for purposes of audio and video synchronization and to determine whether packets have been lost or have arrived out of order. The header also specifies the payload type that allows for multiple data and compression types. To set up an RTP session, the application defines a particular pair of destination transport addresses (one network address and a pair of ports for RTP and RTCP)
1 July 2006
25
1 July 2006
26
RTP Header
Bit: 0 V=2 1
P
RTP Header
31
2
X
4 CC
7
M
8
PT
15
Sequence Number
Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers
The first twelve octets are always present in every RTP packet.
Version (V) (2 bits): Version of RTP. Padding (P) (1 bit): If set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored.
Extension (X) (1 bit): If set, the fixed header is followed by exactly one header extension. CSRC count (CC) (4 bits): The number of CSRC identifiers that follow the fixed header. This number is more than one if the payload of the RTP packet contains data from several sources. Marker (M) (1 bit): Defined by a profile, the market is intended to allow significant events such as frame boundaries to be marked in the packet stream. Payload Type (PT) (7 bits): Identifies the format of the RTP payload and determines its interpretation by the application. Sequence Number (16 bits): Increments by one for each RTP data packet sent, may be used by the receiver to detect packet loss and to restore packet sequence. The initial value is randomly set.
RTP Header
Timestamp (32 bits): The sampling instant of the first octet in the RTP data packet. May be used for synchronization and jitter calculations. The initial value is randomly set. SSRC (32 bits): Randomly chosen number to distinguish synchronization sources within the same RTP session. It indicates where the data was combined, or the source of the data if there is only one source. CSRC List: 0 to 15 items, 32 bits each. Contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field.
RTCP - Real Time Control Protocol

Reference: RFC1889 Facilities provided by the RTCP:
QoS feedback
Receivers in a session report back the quality of their reception from each sender. Feedback includes
Lost packets, jitter, round trip delays
Intermedia Synchronisation
Audio and video are often carried as separate streams but need to be synchronised at the receiver (eg lip sync)
1 July 2006
30
23/07/2010

Identification
RTCP packets contain full details of email, phone number and name of participant - this is available to other participants.

RFC 1889 defines five types of RTCP packets:
RR (Receiver Report) SR (Sender Report) SDES (Source Description Items) BYE APP
Session Control
Allows you to send small notes or say goodbye!!
1 July 2006
31
1 July 2006
32

RR (Receiver Report): These are generated by participants that are not active senders. They contain reception quality feedback about data delivery, including the highest packets number received, the number of packets lost, inter-arrival jitter, and timestamps to calculate the round-trip delay between the sender and the receiver. SR (Sender Report): These are generated by active senders. In addition to the reception quality feedback as in RR, they contain a sender information section, providing information on inter-media synchronization, cumulative packet counters, and number of bytes sent.

SDES (Source Description Items): Contains information about the sources. BYE: Indicates that participation has ended. APP: Intended for application specific purposes. It is only intended for experimental purposes.
RTCP control packets provide the following services:

Quality of Service (QoS) monitoring and congestion control Source identification Intermedia synchronization Control information scaling
1 July 2006
34
RTSP
RTSP or Real-time Streaming Protocol is a client-server multimedia presentation control protocol designed for controlling streaming data over IP networks. It is defined in RFC 2326. It was jointly developed by RealNetworks, Netscape Communications, and Columbia University. It was published in 1998 as a Proposed Standard by the IETF. Streaming breaks data into many packets sized appropriately for the bandwidth available between the client and server.
RTSP
When the client has received enough packets, the user software can be playing one packet, decompressing another and receiving the third. The user can begin listening immediately without the need to download the entire file. RTSP is an application-level protocol designed to work with lower level protocols such as RTP and RSVP to provide a complete streaming service across IP networks.
23/07/2010
RTSP
RTSP provides VCR-style remote control functionality for audio and video streams, i.e., pause, fast forward, reverse, and absolute positioning. Sources of data can include live data feeds or stored files. Because of this RTSP is considered to be more of a framework rather than a protocol. RTSP aims to be what HTTP is to textual data and graphics data. However, there are key differences between RTSP and HTTP:
RTSP
HTTP is a stateless protocol whilst RTSP isnt. The RTSP server has to has to maintain session states in order to correlate RTSP requests with a stream. HTTP is basically an asymmetric protocol, where the client issues requests and the server responds. In RTSP, both the client and server can issue requests.
Listed below are the methods to support the services and operations of RTSP:
OPTIONS: The client or the server tells the other party the options that it can accept. DESCRIBE: The client retrieves the description of a presentation or media object identified by the request URL from the server.
1 July 2006
38
RTSP
ANNOUNCE: When sent from client to server, ANNOUNCE posts the description of a presentation or media object identified by the request URL to a server. When sent from server to client, ANNOUNCE updates the session description in real-time. SETUP: The client asks the server to allocate resources for a stream and start an RTSP session. PLAY: The client asks the server to start sending data on a stream allocated via SETUP. PAUSE: The client temporarily halts the stream delivery without freeing server resources. TEARDOWN: The client asks the server to stop delivery of the specified stream and free resources associated with it. GET_PARAMETER: Retrieves the value of a parameter of a presentation or a stream specified in the URI.
RTSP
SET_PARAMETER: Sets the value of a parameter for a presentation or stream specified by the URI. REDIRECT: The server informs the clients that it must connect to another server location. The mandatory location header indicates the URL the client should connect to. RECORD: The client initiates recording a range of media data according to the presentation description.
RSVP Protocol
Reference: RFC 2205 - 2209 General purpose signalling protocol that allows network resources to be reserved for a connectionless data stream, based on receiver controlled requests.
RSVP
RSVP was jointly developed with Xerox Corp.s Palo Alto Research Center (PARC), MIT and the Information Sciences Institute of University of California (ISI).
Reserve Reserve 1 July 2006 Reserve 41 1 July 2006 Copyright RMIT University 42
23/07/2010
RSVP
RSVP sits on top of IP. However, it is not a routing protocol but an internet control protocol. RSVP relies on the underlying routing protocols to find where it should deliver the reservation requests. RSVP works with unicast and multicast routing protocols. The RSVP reservation process does not actually transmit the data nor does it provide the requested QoS. But it does guarantee that network resources are available when the transmission takes place. It should also be noted that RSVP is just a general facility to distribute reservation parameters; it does not dictate how to set the connection parameters to achieve the requested QoS.
RSVP Data Flows

Packets that pass filter Flowspec Packet Scheduler QoS delivery
Filterspec
Packets of one session (addressed to one destination) Other packets
Best-effort delivery
1 July 2006
44
RSVP Data Flows

Three concepts relating to data flows form the basis of RSVP operation:
Session Flow specification Filter specification
RSVP Data Flows

Flowspec: Specifies a desired QoS and is used to set parameters in a nodes packet scheduler. Filterspec: Defines the set of packets for which a reservation is requested. Both the filterspec and session define the set of packets, or flow that to receive the desired QoS. Any other packets addressed to the same destination are handled as best-effort traffic.
Session: A data flow identified by its destination. Once a reservation is is made at a router by a particular destination, the router considers this as a session and allocates resources for the life of that session. A reservation request issued by a destination end system is called a flow descriptor and consists of a flowspec and filterspec.
Signalling
There are currently 3 major protocols that support signalling in the IP network for VoIP applications, viz:
H.323 MGCP SIP
Signalling
MGCP - Media Gateway Protocol
A control protocol allowing for the monitoring of events in IP phones and gateways and to instruct them to send media to specific addresses.
H.323 and SIP are described in the next few slides.
SIP - Session Initiation Protocol

Protocol developed by IETF for lightweight call control and capabilities negotiation.
47 1 July 2006 Copyright RMIT University 48
1 July 2006
23/07/2010
H.323 Protocol
Reference: ITU-T H.323 Title: Packet-based Multimedia
Communications Systems
H.323 Protocol
Provides: Call control Conferencing functions Call management Capability negotiation Supplementary services
Conceived originally for multimedia conferencing on a LAN, but now extended to cover Internet Telephony. (Revised in 1998)
1 July 2006
49
1 July 2006
50
H.323 Protocol
This Recommendation describes terminals and other entities that provide multimedia communications services over Packet Based Networks (PBN) which may not provide a guaranteed Quality of Service. H.323 entities may provide real-time audio, video and/or data communications.
H.323 Protocol
Support for audio is mandatory, while data and video are optional, but if supported, the ability to use a specified common mode of operation is required, so that all terminals supporting that media type can interwork.
1 July 2006
51
1 July 2006
52
H.323 Protocol
The packet based network over which H.323 entities communicate may be a point-to-point connection, a single network segment, or an internetwork having multiple segments with complex topologies.
SIP
Reference: RFC3261 SIP provides the necessary protocol mechanisms so that end systems and proxy servers can provide services: call forwarding, including
the equivalent of 700-, 800- and 900- type calls; call-forwarding no answer; call-forwarding busy; call-forwarding unconditional; other address-translation services;
callee and calling ``number'' delivery, where numbers can be any (preferably unique) naming scheme;
23/07/2010
SIP
personal mobility, i.e., the ability to reach a called party under a single, location-independent address even when the user changes terminals; terminal-type negotiation and selection: a caller can be given a choice how to reach the party, e.g., via Internet telephony, mobile phone, an answering service, etc.; terminal capability negotiation; caller and callee authentication; blind and supervised call transfer; invitations to multicast conferences.
SIP URI
SIP entities are identified using SIP URI (Uniform Resource Identifier). A SIP URI has form of sip:username@domain, for instance, sip:joe@company.com. As we can see, SIP URI consists of username part and domain name part delimited by @ (at) character. SIP URIs are similar to e-mail addresses, it is, for instance, possible to use the same URI for e-mail and SIP communication, such URIs are easy to remember.
SIP
Extensions of SIP to allow third-party signaling (e.g., for click-to-dial services, fully meshed conferences and connections to multipoint control units (MCUs), as well as mixed modes and the transition between those) are available. SIP addresses users by an email-like address and reuses some of the infrastructure of electronic mail delivery such as DNS MX records or using SMTP EXPN for address expansion. SIP addresses (URLs) can also be embedded in web pages. SIP is addressing-neutral, with addresses expressed as URLs of various types such as SIP, H.323 or telephone (E.164).
SIP
SIP can also be used for signaling Internet real-time fax delivery. This requires no major changes. Fax might be carried via RTP, TCP (e.g., the protocols discussed in the Internet fax WG) or other mechanisms. SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, frame relay, ATM AAL5 or X.25, in rough order of desireability.
1 July 2006
58
SIP Redirect Mode
SIP Proxy Mode
1 July 2006
59
1 July 2006
60
10
23/07/2010
Voice Gateway/Terminal Functions

The following picture shows the functional components of terminals that use the H.323 standards:
Speech
Other Associated Protocols

Among the many protocols relevant to implementations of VoIP are:
TCP, UDP IPv4 and IPv6 ATM and Frame Relay SNMP LDAP WWW etc
Voice Processing
Network Management
SNMP Messages
Call Processing
Signalling
Packet Processing
IP packets
61
1 July 2006
Software Support for VoIP

The software functionality required for voice to packet conversion in a VoIP gateway or terminal device is:
A Voice Processing module
Preparation of voice samples for transmission over the packet network

A Packet Processing module
Processes voice and signalling packets by adding the appropriate transport headers prior to submitting the packets to the IP network. Signalling information is converted from telephony protocols to the packet signalling protocol.
A Call Processing module

Signalling gateway that allows calls to be established across packet networks

A Network Management module
Management agent functionality
Remote fault Accounting Configuration management Security? Dialling directories Remote access support.
Conclusions
This technology is in its infancy! Many problems to overcome.
Hot topics:
Quality of service Echo cancellation Manageability
1 July 2006
65
1 July 2006
66
11
23/07/2010
Conclusions
Many of the protocols that currently support VoIP are not adequate for the task and will need modification before they can be really useful. Need to determine tariff structures also.
12

ICE L9 VoIP 004

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ICE L9 VoIP 004

Загружено:

Авторское право:

Доступные форматы

Internet Communication Engineering

Presentation Outline Voice over IP

Copyright RMIT University

Voice over IP - Technology Guide Series IEEE Network May/June 1999

Copyright RMIT University

Copyright RMIT University

Copyright RMIT University

Internet Communication Engineering

Examples of Possible VoIP Applications

Internet aware telephones

Copyright RMIT University

Copyright RMIT University

Copyright RMIT University

Copyright RMIT University

Examples of Possible VoIP Applications

Remote access from branch or home

Copyright RMIT University

Copyright RMIT University

Internet Communication Engineering

End to End Delay for VoIP PC Phone Call

IP Network Support for Voice

IP Network Support for Voice

Control protocols and mechanisms

IP Network Support for Voice

IP Network Support for Voice

Copyright RMIT University

Internet Communication Engineering

IP Network Support for Voice

RTP - Real-time Transport Protocol

Copyright RMIT University

RTP - Real-time Transport Protocol

RTP - Real-time Transport Protocol

Copyright RMIT University

Copyright RMIT University

RTP - Real-time Transport Protocol

RTP - Real-time Transport Protocol

Copyright RMIT University

Copyright RMIT University

Internet Communication Engineering

RTP - Real-time Transport Protocol

Copyright RMIT University

Copyright RMIT University

Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers

RTCP - Real Time Control Protocol

Copyright RMIT University

Copyright RMIT University

Internet Communication Engineering

RTCP - Real Time Control Protocol

RTCP - Real Time Control Protocol

Copyright RMIT University

Copyright RMIT University

RTCP - Real Time Control Protocol

RTCP - Real Time Control Protocol

RTCP control packets provide the following services:

Copyright RMIT University

Copyright RMIT University

Internet Communication Engineering

Copyright RMIT University

Copyright RMIT University

Copyright RMIT University

Internet Communication Engineering

RSVP Data Flows

Packets of one session (addressed to one destination) Other packets