VOIP ( Voice Over Internet Protocol
VOIP ( Voice Over Internet Protocol
Introduction:
• VOIP refers to using the IP based Networks such as Internet, Intranet and LAN to transmit voice as digitized packets
• Voice signal is digitized, compressed and enclosed in an IP Packet and then transmitted over an IP network.
• Other Protocols are needed to set up and clear the call, negotiate capabilities, determine the location of the user, exchange control information and perform Registration and Admission Control (RAC) functions.
• We shall discuss these Protocols shortly.
• A good VOIP network must be able to provide:
a) Good quality real time audio transmission with minimum delay jitter and packet loss through packet prioritization, echo cancellation, and forward error correction.
b) Seamless integration with PSTN through H.323 or SIP Protocols
c) Security through SSL or L2 Tunnelling or proper Encryption.
d) Inter operability between Vendors through H.323 or SIP
VOIP Architecture:
• Consider the fig shown which demonstrates how VOIP Network works. Draw this picture in the space provided:
• VOIP detailed Architecture: Fig 5.9 p261 F.H or Fig 1 Appendix P546 N .
VOIP Standards and Protocols:
a) H.323 Standards
b) SIP ( Session Initiation Protocol)
H.323 Standards:
• Specifies components, protocols, and procedures for multimedia communication over packet based networks such as IP Telephony, Video Telephony, Audio/Video/ Data transmission etc
H.323 Protocol Stack : See fig 5.6 p257 F.H
• H.323 Protocol interacts with other H.32x series Protocols such as
a) H.324 over Switched Circuit Networks (SCN)
b) H.320 over ISDN
c) H.321 over B-ISDN
d) H.322 over LAN that provide guaranteed QoS
H.323 Components:
a) H.323 Terminals
b) H.323 Gateways
c) H.323 Gatekeepers
d) H.323 MCU (Multipoint Control Units)
H.323 Zone:
• See fig 1 H.323 Associated Protocols Ohio
• An H.323 Zone is a collection of all terminals, gateways and MCU’S managed by a single Gatekeeper
• Terminals, Gateways and MCU’S are called endpoints
• Each endpoint has a unique network address and may also have an ALIAS Address similar to email address or telephone number.
H.323 Terminals:
• Consider fig 12.39 L.I P801
• An H.323 Terminal is either a PC running H.323 Protocol Stack or a USB IP Telephone.
• As seen in the fig, an H.323 Terminal implements:
a) H.225 RAS for Registration, Admission and Status control
b) H.225/Q.931 for Call set up and Call clear
c) H.245 for System Control
d) G.711/722/723.1/728/729 for Audio coding
e) H.261/263 for Video Coding
f) RTP (Real Time Protocol)/ RTCP (Real Time Control Protocol)
Mandatory Standards:
• Refer to table 5.1 P250 F.H for complete mandatory Standards Summery.
• It is clear that H.323 Standards are comprehensive, complex and flexible and therefore difficult and costly to implement . That’s why very slow adoption and deployment. It is often compared with ATM. Too much too soon. Probably the world is not ready for it yet. SIP is a simpler protocol, but it came in the market too late. Currently, H.323 dominates the market in terms of current deployments. We will concentrate on only those aspects of H.323 that relates to VOIP applications
VOIP Gateways ( G/W):
• A G/W is located between two dissimilar Networks e.g for VOIP, between PSTN and IP Network
• Performs data format conversion, control and signaling translation and Audio and Video codec translation between two dissimilar Networks
• Also performs Call setup and teardown on both sides of the Network
• Specifically, it performs following functions for VOIP application
a) The interface and signaling between the IP and PSTN
b) Call setup and Clearing
c) Digitizing, compression, decompression and packetizing of the voice signals
d) Translation between Telephone Numbers and IP Address
e) Echo Control, silence suppression, forward Error control
f) Delay and jitter control
g) QoS (Quality of Service)
A G/W implements protocols specific to the Networks it is interfacing such as H.245, 225 RAS, 225 Call Setup, RTP/RTCP/H.10, H.320, H.324, H.322 etc. See fig 4 P9 Trillium Tutorial on Web Proforum.
VOIP Gatekeepers:
Refer to fig 10 Trillium Tutorial
• Implements 225 RAS, RAS Signaling and 245
• A G/K is the “brain” of an H.323 based Network and acts as a “Manager”
• Performs following vital functions
a) Registration and Admission Control
b) Call Authorization
c) Call signaling
d) Call Routing
e) Call Management
f) BW Management
g) Accounting, billing and charging.
MCU’S:
• Manage multipoint conferences of 3 or more H.323 Terminals
• Provide support for managing conference resources, negotiate audio and video capabilities between terminals
• May even handle Media stream
Note: Although G/W, G/K and MCU are logically different entities, they may be implemented in a single physical device.
VOIP PTOTOCOLS:
• Refer to VOIP Protocol Stack Fig 2 Ohio.
• Notice that Audio/Video stream is transmitted as an RTP/RTCP/225 RAS packet enclosed within a UDP Packet
• Control and Signaling messages use a variety of packets-225/Q.931 for call signaling, 245 for call control and enclosed within a TCP Packet
• We shall now look at each of these Protocols to understand how they function together to produce a reliable voice conversation over the Internet
AUDIO CODECS:
G.711: - 64Kbps PCM (Mandatory)
G.722: - 50 Hz to 7KHz ADPCM
G.728: - Also uses ADPCM coding at 16 Kbps but improved speech up
to 3.4 KHz
Now a days most H.323 terminals support G.723.1 codec, which is more efficient and produces good quality audio at 5.3Kbps and 6.3 Kbps
VIDEO CODEC:
H.261: - MPEG 1,2
H.263: - Over Wireless and PSTN
• Details on P215 F.H and Ohio.
H.225 RAS: Registration, Admission and Status Control Protocol:
• Defines communication between the end-points and G/K
• Necessary only when a G/K is present
• Uses UDP for delivery in an IP environment
• Performs following functions
a) G/K discovery message: Endpoints use discovery messages to find out their Gatekeepers. Broadcast messages are sent. G/K responsible for the zone responds with its transport address
b) Endpoint Registration message: All endpoints must register with the G/K in that zone and inform the G/k and inform the G/K of their transport and Alias addresses so that the G/K can properly route calls to correct destinations.
c) Endpoint location message: G/K use this message to update its database.
d) Admission, BW change, Status and Disengage messages: are used for admission control, BW management, status determination and disconnection.
H.245 Media Control Messages:
• Used to negotiate compatibility settings before actual audio, video or data communication links are established.
• Provides following Media Control functions:
a) Compatibility exchange e.g. media types, codecs, bit rates etc
b) Opening and closing of logical channels: Audio and Video channels are unidirectional whereas data channels are bi-directional. Uses channel “0” for control messages.
c) Flow control messages
d) General comments and status messages
• H.245 control is mandatory in all endpoints
• Transported over reliable TCP.
H.225 Call Control Protocol:
• Used to exchange call set up and clearing messages between endpoints
• Transported over TCP
• Refer to figs 6/7/8/9 on p15/16/17/18 Web proforum
RTP (Real time Transport Protocol): (See fig 12-21 F.H P820-824 or P793-797 I0
• There are 3 major factors that affect audio call quality.
a) Delay
b) Jitter
c) Packet loss
• Delay manifests itself as a walkie –talkie effect. Maximum tolerable delay is 150 ms.
• Jitter is difference in delays of the arrival time of different packets. Its effect is the same as that of the packet loss i.e. missing words or garbled words. For Video transmission it causes flickering. Maximum tolerable jitter is 250 ms
• Packet loss causes missing and garbled words as mentioned earlier.
• RTP is designed to minimize the effects of these factors
• RTP supports transmission of real time data ( Audio and Video) over data networks. It works in conjunction with RTCP and contains fields to detect loss packets and provisions for compensating delays and jitter.
• RTP protocol provides following functions
a) Sequencing: To detect loss packets
b) Payload Identification: In the Internet, it is often necessary to alter the encoding of the media dynamically to adjust to changing BW availability. The Payload ID describes the encoding of the media
c) Frame Indicator: Audio and video streams are sent as Frames. To indicate the beginning and end of the frame, a frame Marker bit is provided
d) Source IP: Source Identification is needed in a multicast session. SSRC field in the RTP Header identifies the originator of the frame
e) Timestamp: Timestamp field is provided to calculate and compensate for delay and Jitter.
RTCP: Real Time Control Protocol: Provides following control functionalities:
a) Synchronization: RTCP packets provide synchronization of video and audio stream so that they can be played back together
b) QoS: Participants periodically send RTCP packets to exchange information regarding # of packets loss, round trip delay, jitter etc. This information helps sources to adjust their data rates dynamically.
c) Identification: RTCP packets carry information such as email address, name and phone #s etc so that the participants know the identity of each other
d) Session Control: Provide Session Control via “ BYE” packet when a participant leaves a session.
e) Complete RTP and RTCP packets are shown below ( P820-824 F.H or P793 –797 I.) ( Photocopy P820 Fig 12-21 F.H)
Description of various fields in the RTP packet:
V: 2 bit field defines the version. Current version is 2
P: Padding bit: 1 bit: When set, indicates the existence of padding bytes at the end of the header to be ignored by the receiver. These padding bytes are not part of the payload. The last byte of the padding contains a count of how many padding bytes are to be ignored including it.
X ( Extension): ( 1 Bit): When set, the fixed header must be followed by exactly one header extension. ( to be defined and added in future)
CSRC Count (CC): A 4 bit field that indicates how many participants are currently contributing to the session. With 4 bit field, up to 15 participants are allowed. This field is used for Multicast Calls.
M ( Marker): (1 Bit): Since different types of CODECS generate digitized streams in different frame formats, this 1 Bit field is a profile which enables the RCVR to correctly interpret the digital data on the correct frame boundaries. It works with the PT field defined below.
PT ( Payload Type): ( 7 Bit field): Identifies the type of CODEC being used.
SEQ # ( 16 Bits): This randomly selected # increments with every packet sent. Used by the receiver to detect lost or out of sequence packets. No Retransmission mechanism exists. Normally, last correctly received packet is played again. Buffering a number of packets before play out minimizes the effect of out of sequence packets. This of course increases delay slightly which must be taken into account in the overall design of the VOIP network.
Time Stamp: (32 Bits): This 32 bit number specifies the sampling instant of the first byte in the RTP data packet. This number is used at the RCVR to calculate delay, jitter and synchronization as follows:
Delay = Transmitter Time Stamp minus Receiver Time Stamp
Jitter =variation in various delays.
This information is periodically exchanged via RTCP by all participants to adjust their compression algorithm to maintain the QoS .
SSRC( Synchronization Source): Identifies the source device that has generated the contents of the packet ( or where it was combined) such as microphone, camera, PC etc. The receving RTP uses SSRC to relay the reconstituted bit stream to the correct output device interface.
CCRC list: Contains the IP address of the contributing sources ( all participants IP Addresses).
RTCP:
• Provides feedback on the QoS parameters such as delay, jitter, packet loss in the form of Sender and Receiver reports ( SR and RR).
• Also carries information about the participants email addresses, Telephone #s etc called Canonical Names (CNAME)
• CNAMES are also used to synchronize audio and video streams in related session to achieve lip synchronization (meaning when a person speaks in a picture, his lips and voice must be synchronized)
• Provides following packets:
• SR, RR, Source Description (SDES), CNAME, BYE, APP ( Application Specific function)
Note: Refer to article “ Planning VOIP Networks” for details about delay, jitter and packet loss Calculations
SIP (Session Initiation protocol)
Introduction:
• Refer to fig 9.9 P562 F.H to understand the general architecture of the global Internet.
• TP telephony requires supporting multiparty calls involving audio, video and data streams to be carried in a dynamic way
• Furthermore, any participant can join or leave a session any time
• Also, the location of the participant may change in time. A participant, for example, may be attached to an enterprise network at one time and, while at other time to a Home PC, or a PSTN Telephone or a Cellular phone.
• IP telephony must support following functions
a) Call Establishment and Teardown
b) Dynamic user location
c) Negotiations of a suitable set of capabilities that are supported by all parties involved.
IETF( Internet Engineering Task Force:
• IETF defined following protocols to address most of these issues. They are described in RFC 2543.
a) SIP: Session initiation Protocol
b) SDP: Session Description Protocol
c) GLP: Gateway Location protocol
d) MGCP: Media Gateway Control protocol
e) SAP: Session Announcement protocol
f) RTSP: Real time Streaming Protocol
g) RSVP: Resource Reservation Protocol and a few more protocols
SIP: Session Initiation protocol:
• This is the IETF’S Standard for establishing VOIP connection
• It is an application layer control protocol for establishing, modifying, managing and terminating VOIP, Video and Data calls with one or more participants
• SIP uses the REQUEST/RESPONSE ( or COMMAND-METHOD ) structure of HTTP with CLIENT- SERVER MODEL. See fig below
USER A USER B
REQ
RES
REQ/RES
• Client generates the Request and the Server generates the Response. A pair of REQUEST/RESPONSE is called a TRANSACTION
• Both the REQUEST and RESPONSE are created through an application process called a USER AGENT (UA)
• Each UA consists of two parts: A UA CLIENT (UAC) and a UA SERVER (UAS).
• A UAC creates Requests such as a message to initiate a call
• A UAS processes the Request and generates a Response message based on the Request.
• Fig shows (fig 14.17 p 914 F.H) the protocols involved in a SIP Session as well as the SIP messages such as INVITE, ACK, REGISTRATION, OPTIONS, CANCEL, BYE etc.
• Each REQUEST/RESPONSE message consists of a HEADER and a BODY
• Fig below shows the format of an INVITE message.
• As shown above, the HEADER contains a list of items similar to email and the body contains information regarding media streams to be used (CODEC Specs etc) in the call. SIP depends upon the companion SDP (to be defined shortly) to define media capabilities.
• SIP uses text format and email style names and addresses with a sip added in the front for example
Sip: hyder.k@humber.ca or sip: george.l@alcatel.ca
• This requires that the IP address of the called party must be known first before SIP messages can be sent over the Internet
• Since a user may be at any one of a number of different locations, at the time of the call, a user must register with the IP telephony service provider all possible SIP locations where he/she could be found.
• For example, hyder.k could be found either at sip: hyder.k@humber.ca or at sip hyder.k@uoguelph.ca or at a PSTN # 416-675-6622 or a mobile phone 416-455-1720
• This list of addresses is sent to another SERVER called REDIRECT-SERVER at each of the sites involved e.g humber.ca and uoguelph.ca using a register message.
• Notice that SIP still uses RTP and RTCP to actually transport real time traffic, which is then enclosed in a UDP and IP Packet
EXAMPLE:
• Assume the called user is currently at the given sip Address. Fig 14.18a F.H shows the protocols and the network components involved in the call set up.
• Assume that the sip address of the calling user is sip: hyder.k@humber.ca and that of the called user is sip: judy.z@.
• Every access network has a 2nd server called the Proxy Server to which all SIP INVITE messages are sent e.g PS-A and PS-B in the fig. Each host knows the IP Address of its Proxy Server and the Proxy Server knows the SIP address of each user that is currently logged in at the site. It also knows the IP address of the user’s host device. SIP names and Addresses are obviously entered by the Network Administrator, but how does the Proxy Server know the IP Address of the host? __________( ARP)
• When the PS-A receives an INVITE Request message, it first reads the SIP name /Address of the called party from the TO: field in the HEADER, and determines the IP Address of the PS-B for using what?________ (DNS). Once it obtains the IP address of the PS-B, it sends the INVITE message to PS-B.
• PS-B reads the SIP name of the called party from the TO: field of the header and determines that judy.z is currently logged in at this location and also its IP address using ARP. It then uses this IP Address to send the INVITE REQUEST to the called host.
• Assuming that the called host accepts the call, an INVITE RESPONSE message is sent over the same path
• When the calling host receives this response, it sends an ACK message to the called host and the conversation begins
EXAMPLE 2:
• Now assume that the called party is currently at sip: judy.z@ and not at . See fig 14.18b F.H.
• This time, on receipt of the INVITE message from PS-A, PS-B determines that judy.z is not currently logged in to this site.
• It then forwards the request to REDIRECT SERVER for the site RS-B, which has a list of alternate addresses for the called party and determines that judy .z can also be located at .
• The SIP in RS-B returns this information in a CONTACT: header field in the INVITE Response message. On receipt of this, PS-A proceeds as before but this time by first obtaining the IP Adddress of the SIP Proxy Server at using DNS.
SDP (Session Description Protocol):
• SDP is a companion protocol used to describe the different Media streams involved in the call as well their addresses and UDP Port #s etc. This information is contained in in SIP message body in a simple textual format and includes:
(a) Media Streams: Speech, Audio, Video and Data. Each SIP INVITE Request message contains a list of acceptable (to the caller) media types and compression formats and the INVITE RESPONSE message contains similar information from the called party.
(b) Stream Addresses: For each Media Stream, the destination addresses and Port #s for sending and Receiving
© Start and Stop Lines: Used with Broadcast session to enable a user to join a session any time during the broadcast.
The Gateway Location Protocol (GLP):
• In the previous 2 examples, we considered the cases when both hosts (or more for multiparty calls) are directly connected to Internet (PC-to-PC Calls)
• Now we consider the example when one or more of the participants are connected to a different network such as PSTN/ISDN/Cellular Network.
• In this case the job is to find a Signaling Gateway closest to the called and/or calling user so as to utilize Internet resources for as much of the connection path as possible in order to avoid PSTN/ISDN/Cellular long distance charges. The ultimate goal is to by-pass the toll-charging Network all together.
• Refer to Fig 9-9 F.H, which shows global Internet as well as the Regional, National and Access Network.
• Also notice that there are a number of Gateways associated with Access/Regional and National Networks.
• Also Notice that each of the Network has one or more LOCATION SERVERS (LS).
• Now refer to fig 14.19 P918 F.H, which shows how a SIP Call will be routed to a different Network
• LS help find a Gateway that is closest to the PSTN or ISDN or Cellular Network to which the called host is attached. The SIP INVITE Message is sent to this Gateway.
• The GW knows the Regional/National code of the PSTN/ISDN/Cellular segment to which it is connected (entered by the Network Administrator)
• On the Internet side, GW has an IP address as well as the it knows the IP address of the LS that is attached to the same Internet or Regional/National Network.
• Each GW uses the the IP Address of the LS to inform it of the Regional/National code of the PSTN/ISDN/Cellular network to which it is directly connected.
• Each LS then exchanges this information with other LS using GLP. This way all LS build a database of the IP Address of the L Servers that should be used to reach all of the Gateways connected to other Regional and National Networks and also convey their corresponding PSTN/ISDN/Cellular Codes
• This process sounds familiar? What Protocol is this? You learnt it in Data Network Course______________ (BGP)
RTSP (Real Time Streaming Protocol):
• RTSP is a Client Server Protocol that provides “VCR “ style remote control functions for Audio and Video streams such as fast forward, rewind, pause etc.
• It also provides the means for choosing delivery channels such as UDP, TCP etc as well as delivery mechanism such as RTP.
• RTSP establishes and controls streams of continuous audio and video media between the media Servers and Clients
• Media Server provides playback and recording services for the media stream whereas a Client requests continuous media data from the media server.
• RTSP acts as the “ Network Remote Control” between the server and the Client.
• RTSP is an application level Protocol with syntax and operation similar to HTTP, but works for audio and video. However, unlike HTTP, in RTSP both Servers and Clients can issue Requests. It uses URLS similar to HTTPRTSP is implemented on multiple operating system platforms and it allows interoperability between Clients and Servers from different manufacturers.
RSVP (Resource Reservation Protocol):(p696 702 I)
• RSVP is a Protocol developed by IETF to provide QoS and guaranteed Latency. It is because of RSVP that VOIP has become a reality today.
• RSVP allows prioritizing traffic by reserving resources at each node along the data path.
• It requests reservation of resources in only one direction.
• It treats a sender as logically different from the Receiver, although the same application process may be acting as both a Sender and the Receiver
• It makes the RCVR responsible for requesting a specific QoS.
• A QoS request from a RCVR host application is passed to the local RSVP process, which then carries the request to all nodes along the reverse data path to the data source.
• Thus RSVP is RCVR oriented.
• It supports both unicast and multicast
• It maintains soft states in Routers and Hosts, providing support for dynamic membership changes.
Integrated Services in the Internet
• As we know, the Internet provides only the best effort service to everyone regardless of the type of traffic.
• Thus Internet is not suitable for applications that require a certain amount of guaranteed BW such as voice and video.
• IETF developed the Integrated Services Model to ensure that a certain degree of QoS can be provided for such applications
• The Model contains provisions to allow a certain amount of Network Resources (such as BW and Buffers) to be explicitly reserved for such applications to meet the QoS requirements of the application.
• Fig below shows the Router Model in the Integrated Services IP(fig 10.18 p 694 I). Draw this picture in the space provided.
• Packet Classifier: Identifies the flows that are to secure a certain level of service
• Packet Scheduler: Forwards packets in a manner that ensures that the QoS commitments are met
• Admission Control: determines if a Router has the necessary resources to satisfy the requested QoS. If it has then it accepts the flow.
Details of the RSVP Operation:
• RSVP is used to provide messages to set up a flow with a requested QoS across the Network.
• RSVP messages inform each Router in the path (up to the Destination Router) of the requested QoS, and if the flow is found admissible, each Router in turn adjusts it Packet Classifier and Packet Scheduler to handle the given packet flow.
• A Flow Descriptor is used to describe the traffic and the QoS required of a flow
• The Flow Descriptor consists of 2 parts- a Filter Spec and a Flow Spec
• The filter Spec contains information required by the Packet Classifier to identify the packets that belong to a particular flow
• The flow spec has 2 parts- the Traffic Spec(Tspec) and a Service Request Spec(Rspec) .
• The Tspec describes the traffic behaviour of the flow
• The Rspec specifies the requested QoS in terms of BW, Jitter, delay, packet loss etc
• RSVP requests resources in one direction only, from the sender to the RCVR.
• RSVP is RCVR oriented, i.e the RCVR initiates the reservation request. This is useful, since for multiparty sessions, a receiver can join the conference any time and leave the session any time. Also because, receiver actually knows what QoS it requires.
• RSVP supports both IPV4 and IP V6.
• To enable Resource Reservation, an RSVP process( or daemon) in each node has to interact with other modules in the host as shown in the fig 10.19 p696I.
• If the node is a Host, then the application requiring the QoS first makes a request to an RSVP process that, in turn, sends RSVP messages from one node to other.
• RSVP process passes control to its own two local control modules the Policy Control and Admission Control
• These Modules determine the admissibility of the request based on the availability of sufficient resources, authentication, accounting and access control.
• If the request is found admissible, parameters are set in the Packet classifier and Packet Scheduler to satisfy the request. If not an error message is sent to the originating application..
• In RSVP, a session is defined to be data flow identified by its destination IP Address, IP protocol #, and optionally, the destination port # ( could be unicast or multicast).
• The Sender sends Path Messages to the RCVR( or RCVRS) that include information regarding the path, sender IP Address and Sender Tspec
• Receiver then sends the Reserve messages along the reverse path.
• When there are multiple RSVRS, the resources are not reserved for each receiver separately, but are shared up to the point where the paths to different receiver diverge.
RSVP Message Format:
• Each RSVP message consists of a common Header and a body consisting of a variable number of OBJECTS that depend on the message type. The information contained in the Objects is used to make resource reservation
• Fig below shows the format of the RSVP Header
VERSION =1
NO Flags defined yet
Message Type: Currently 7 message types as follows:
PATH, RESV, Path Error, Resv Error, Path Tear, Resv Tear, Resv Conf.
CHECKSUM: is 1’s complement Algorithm used for TCP/IP
SENT TTL: Sent Time to Live
Reserve Length. Total Length of the Resrv message in Octets, including Header
• The format of the OBJECT is shown below:
LENGTH: Indicates total length in octets (must be a multiple of 4).
CLASS-NUM: Specifies the Object Class
C-TYPE: Indicates the subclass of the Object
The body contains objects information such as session, flowspec, filterspec, Tspec, policy data, integrity (such as cryptographic and authentication information etc.)
MGCP (Media Gateway Control protocol)
• Current voice Gateway implementation consists of two components
a) The Signaling Gateway
b) Media Gateway
• The Signaling Gateway communicates with the Media Gateway using MGCP
• MGCP can operate with both SIP and H.323
• Fig below shows current implementation of VOIP protocol Stack
MGCP:
• It is a protocol that defines communications between Call Control Elements (Call Agents) and Telephony Gateways
• Call Agents are external call control elements located outside the Gateways and are also called Media Gateway Controllers ( MGC)
• MGCP is a control protocol that allows a control coordinator to monitor events in IP phones and gateways and instructs them to send media to specific addresses.
• Gateways execute commands sent by the call agents
• It uses the concepts of connection and endpoints for establishing voice path between two participants, and the concept of events and signals for establishing and tearing down calls.
• Endpoints are the sources of data such as an interface on a GW that terminates a trunk connected to a PSTN switch
• A Connection is a point to point or point to multipoint association between two endpoints. Once the association is established, data transfer can take place.
• Connection can be established over TCP/IP or ATM etc
• A Call Agent may ask to be notified about certain events occurring in the endpoints such as off-hook, on-hook, dialed digits, etc and also may request that certain signal be applied to the endpoints such as dial tone, busy tone, and ringing.
Creating Connection: When two endpoints are located on Gateways that are managed by the same Call Agent:
• The Call Agent asks the first GW to create a connection on the first endpoint. The response sent by the GW includes Session description
• The Call Agent then sends the Session description of the first GW to the 2nd GW and asks to create a connection on the 2nd endpoint.
• The 2nd GW responds by sending its own Session description.
• The Call Agent uses a “ modify connection Command “ to provide the session description to the first end point.
• Now communication can start in both directions
• When two endpoints are located on GWS that are managed by different Call Agents, they exchange information using Call Agent to Call Agent Signalling Protocol, in order to synchronize the creation of the connection on two endpoints
MGCP Commands: Uses transactions that consist of 8 commands and Responses.
(a) Create Connection: Used to attach an endpoint to a specific IP address and port.
(b) Modify Connection: Used by the Call Agent to modify the parameters of an active connection.
(c) Delete Connection: Deletes an existing Connection. Used either by a Call Agent or a GW.
(d) Notification Request: This command is used by the Call Agent to be notified of specific events such as onhook/offhook, dialed digits etc
(e) Notify: Response from the GW to Notification Command.
(f) Audit Endpoint: Command from the Call Agent, requesting Status Information of the endpoint
(g) Audit Connection: The Call Agent uses this Command to obtain specific information of an endpoint.
(h) Restart in Progress: Used by the GW to indicate that one or more endpoints have been taken out of service.
Comparison of H.323 and SIP:
• Read page 4 of the article “Voice over IP Protocols and Standards”
IP Telephony Products and Services:
• The paper “ VOIP products, Services and Issues” provides an extensive list of H.323 compatible Terminals, Gateways, and Gatekeepers. Also, IP web site gives a lot of Tutorials and VOIP products and services. Here we shall discuss currently available Multipoint Control Unite (MCUS) and some IP telephony Service providers.
• MCUS are needed where a lot of users participate in a multimedia conference such as a Virtual Corporate meeting.
• MCUS are available in two configurations.
• SERVERBASED: Built on a server platform like a PC running Windows NT, with appropriate software and add-in hardware boards.
• RACK-MOUNTED: Rack-mounted MCUS use proprietary hardware and software to provide multiparty conference.
• Following is a list of commercially available MCUS and their features:
(a) EZENIA NETSERVER:
• Server based running under Windows with add-in media stream processing card.
• Supports up to 32 H.323 or 48 T.120 users
• Supports H.261, H.263, G.711, G.723.1, G.728
• Supports mixed endpoint CODEC capability in the same conference.
• Uses SNMP for monitoring
• Built-in Gatekeeper, but can also work with external Gatekeeper
• Another name for Ezenia is “VIDEO SERVER”
(b) White Point Software meeting Point 4: Server based for Windows and Sun Solaris
© PictureTel 33 NetConference Multipoint Server Seoftware: Server based
(d) Lucient Technology Multimedia Communication Exchange (MMCX): Rack-Mounted
(e) RADVision MCU-323: Rack-mounted
ITSPS: Internet Telephony Service providers:
• ITSPS maintain Gateways from PSTN to the Internet and provide low cost telephony service to traditional phones and fax machines
• Depending upon the proximity of the Gateway to the PSTN where a call is placed, the savings could be significant
• Foe example Net2 Phone provides rate of about 3 cents/minute for calls within the U.S and 6 cents/minute for calls to most areas in Europe
• Net2 Phone Service is based on proprietary software that is not H.323 compliant.
• ISPS normally provide following services:
PC-to-Phone
Phone-to-Phone
PC-to-Fax
• Following is a list of ITSPS:
Access Power: PC-to-Phone, Phone-to-Phone
BIZTRANS: PC to phone, phone to phone, fax
COOLCALL-CON: Phone-to-Phone
Cyberfax: Fax
Delta 3: Pc-to-phone, Phone -to-Phone
EuroCall:
Global Exchange Carrier
Innofone
GlobalNet Telecommunications
World Wide Talk
Vocaltec
-----------------------
UAC
UAS
UAS
UAC
0 - 3 4 –7 8 - 15 16 - 31
VERSION FLAG MESSAGE TYPE RSVP CHECKSUM
SEND TTL SEND TTL RSVP LENGTH
0 - 15 16 - 23 24 - 31
LENGTH CLASS-NUM C-TYPE
OBJECT
RTP
RSVP
RTCP
SIP
SAP/SDP/RSTP
H.
323
UDP TCP
NETWORK
DATALINK
PHYSICAL
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- title wireless structural sensors using peer to peer
- packet scheduling algorithm for video streaming over
- survey of transport protocols other than standard tcp
- author guidelines for 8
- voip voice over internet protocol
- a comparison between three heuristic combinatorial
- a performance comparison of hypertransport vs
- a comparison of http and https performance
Related searches
- aip protocol food list printable
- betadine protocol viral conjunctivitis
- aip protocol food list
- autoimmune protocol diet print out
- autoimmune protocol food list
- sample protocol template
- time out protocol in surgery
- crps physical therapy protocol pdf
- joint commission universal protocol checklist
- xfinity voice and internet bundle
- xfinity voice and internet only
- comcast internet and voice deals