SESSION INITIATION PROTOCOL

SESSION INITIATION PROTOCOL

Author : Abhishek Kumar

Indian Institute of Technology, Madras

Computer Networks Presentation

22.4.2008 Počítačové sítě 2

SIP : The way to the future

The era of separate voice and data networks is gradually nearing an end. In the future, a single, converged network will provide the basis for all forms of communication. In addition to reducing costs, that convergence will enable a whole new range of services. The Session Initiation Protocol (SIP) will be the control mechanism at the center of this revolution.


What is SIP ?

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants.

These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution.Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. It was standardized by the IETF under RFC-3261 which obsoletes the previous standardization of SIP under RFC 2543.


SIP applications

setting up voice-over-IP calls setting up multimedia conferences event notification (subscribe/notify) such as IM and

presence text and general messaging signaling transport


Protocols used under SIP

Session Description Protocol (SDP) : (RFC-2327)

Used to describe which media will be used. Resource Reservation Protocol (RSVP) :

(RFC-2205)

Used for reserving network resources.

Session Announcement protocol (SAP) : Used for advertising multimedia sessions via multicast.


SIP related Protocols

Real-time Transport Protocol (RTP) : (RFC-1889) Used for transporting real-time data and providing QOS feedback.

Real-time Transport Control Protocol (RTCP) : Used to control the RTP channel.

Real-time Streaming Protocol (RTSP) : (RFC-2326) Used for controlling delivery of streaming media.


Multimedia Communication Architecture


The Protocol Stack


SIP protocol use


SIP Concepts and Elements A user agent (UA) : an end-point, lets users create and manage a

communication session.

IP phone, PC software, Conference Bridge handles session setup and management tasks (transfer,

termination, and service invocation) Identifies user availability and negotiate session capability.


SIP Concepts and Elements User Agent Client (UAC) : a client application that initiates SIP

requests.

User Agent Server (UAS) : a server application that contacts the user when a SIP request is received and then returns are response on behalf of the user.


SIP Concepts and Elements A SIP proxy server : Handles registrations, implementing call-

routing policies, and performing authentication and authorization. Interprets, and, if necessary, rewrites specific parts of a request

message before forwarding it. A SIP messages may pass through many SIP proxy servers as it

travels to callee UA. A UA can be configured to send any requests to a specific SIP

proxy server, known as Outbound Proxy Server.


SIP Concepts and Elements Redirect Server : is a server that accepts a SIP request, maps the

SIP address of the called party into zero (if there is no known address) or more new addresses and returns them to the client.

Unlike Proxy servers, Redirect Servers do not pass the request on to other servers.


SIP Concepts and Elements SIP Location Server (Registrar) : is a server that accepts

REGISTER requests for the purpose of updating a location database with the contact information of the user specified in the request.

Session : is established when the UA (the caller) invites another UA (the callee) to join a communication session.


SIP Concepts and Elements A SIP message : is a text-based request/response model

similar to the HTTP protocol.

There are two types of SIP messages : Request : sent from the client to the server. Responses : sent from the server to the client.


Request Methods

Method Description

REGISTER Creates and manages registrations.

INVITE Initiates a communication session and is sent from the caller to the callee inviting them to join the session.

ACK Sent by the caller after a final response has been received for an INVITE request.

BYE Sent from caller or callee to terminate the session.

CANCEL Used to CANCEL an INVITE request for which a final response has not yet been received.

OPTIONS Queries the capabilities of the other side.


Response Methods

Method Description

1xx Information Provides progress response to the caller, for example 100 Trying, 180 Ringing.

2xx Success Confirms that a request has been accepted

3xx Redirect Notifies the caller of an alternative location to where the request should be sent.

4xx Request Failure Indicates that a request has not been processed successfully; for example, 404 Not Found.

5xx Server Failure Indicates that the server itself has erred.

6xx Global Failure Indicates a global failure regarding a particular user.


Response code examples 100 Continue 180 Ringing 200 OK 300 Multiple choices 301 Moved permanently 302 Moved temporarily 400 Bad request 401 Unauthorized 403 Forbidden

408 Request time-out 481 Call-leg/Transaction does not

exist 482 Loop detected 5xx Server error 600 Busy 603 Decline 604 Does not exist 606 Not acceptable


SIP Messages

SIP messages are composed of the following three parts: START LINE : Every SIP message begins with a Start Line. It conveys

the message type (method type in requests, and response code in responses) and the protocol version. The Start Line may be either a Request-line (requests) or a Status-line (responses), as follows:

Request-line includes a Request URI, which indicates the user or service to which this request is being addressed.

The Status-line holds the numeric Status-code and its associated textual phrase.


SIP Messages

HEADERS : SIP header fields are used to convey message attributes and to modify message meaning. They are similar in syntax and semantics to HTTP header fields and thus always take the format:

<name>:<value> Headers can span multiple lines. Some SIP headers such as Via, Contact,

Route and Request-Route can appear multiple times in a message or, alternatively, can take multiple comma-separated values in a single header occurrence.


SIP Messages Every SIP message requires certain mandatory headers : To: A SIP address containing the request's destination. From: Indicates who has originated the request. CSeq: Contains a command sequence, which ensures that messages are dealt with

in the order they were generated. Call-ID: The SIP proxy server uses the Call-ID header, a randomly generated string

that uniquely identifies the session, to identify messages belonging to a session. Via: Contains information about what SIP devices the message has passed through

as it moves between caller and callee. The Via header, moreover, routes a response in the reverse direction, through the same SIP devices as the request.

Contact: Contains the actual location of the callee, which might be different from the address of the originator in the From header.


SIP Messages

BODY (CONTENT) : A message Body is used to describe the session to be initiated (for example, in a multimedia session this may include audio and video codec types, sampling rates etc.), or data of any type which relates in some way to the session.

Message bodies can appear both in request and in response messages. Possible body types include: SDP - Session Description Protocol (SDP). Multipurpose Internet Mail Extensions (MIME). Others - to be defined in the IETF and in specific implementations.


SIP Addressing A SIP address : (also known as a SIP URL) uniquely identifies a user

during the creation of a communication session. The address resembles an e-mail address except that it has a sip: prefix.

For example [email protected] written as URL, sip:[email protected] .

We can also can use tel URLs for telephone numbers, such as : tel:+91-011-23381060 or fax:+358.555.1234567

We can use either global (tel:+1...) or local (tel:0w003585551234567) SIP allow post-dialing digits: ;postd=pp32 Allows URL such as modem:+3585551234567 .


SESSION ESTABLISHMENT

CALL FLOW1) The calling User Agent Client sends an INVITE message to Bob’s SIP address:

sip:[email protected]. This message also contains an SDP packet describing the media capabilities of the calling terminal.

2) The UAS receives the request and immediately responds with 100-Trying response message.

3) The UAS starts “ringing” to inform Bob of the new call. Simultaneously a 180 (Ringing) message is sent to the UAC.

4) The UAS sends a 182 (Queued) call status message to report that the call is behind two other calls in the queue.

5) The UAS sends a 182 (Queued) call status message to report that the call is behind one other call in the queue.

6) Bob picks up the call and the UAS sends a 200 (OK) message to the calling UA. This message also contains an SDP packet describing the media capabilities of Bob’s terminal.

7) The calling UAC sends an ACK request to confirm the 200 (OK) response was received.


SESSION ESTABLISHMENT


SESSION TERMINATION

The session termination call flow proceeds as follows:

1) The caller decides to end the call and “hangs-up”. This results in a BYE request being sent to Bob’s UAS at SIP addresss ip:[email protected].

2) Bob’s UAS responds with 200 (OK) message and notifies Bob that the conversation has ended.


Call Redirection

CALL FLOW

1) First a SIP INVITE message is sent to [email protected], but finds the Redirect server sip.acme.com along the signaling path.

2) The Redirect server looks up Bob’s current location in a Location Service using a non-SIP protocol (for example, LDAP).

3) The Location Service returns Bob’s current location: SIP address [email protected]) The Redirect Server returns this information to the calling UAC using a 302 (Moved

Temporarily) response. In the response message it enters a contact header and sets the value to Bob’s current location, [email protected].

5) The calling UAC acknowledges the response by sending an ACK message.6) The calling UAC then continues the transaction directly with gw.telco.com by sending a new

INVITE.7) gw.telco.com is able to notify Bob’s terminal of the call and Bob “picksup” the call. A 200 (OK)

response is sent back to the calling UAC.8) The calling UAC acknowledges with an ACK message.


Call Redirection


Call Proxying

CALL FLOW

1) An INVITE message is sent to bob@ acme.com, but finds the Proxy server sip.acme.com along the signaling path.

2) The Proxy server immediately responds with a 100 (Trying) provisional response.3) The Proxy server looks-up Bob’s current location in a Location Service using a

non-SIP protocol (For example, LDAP).4) The Location Service returns Bob’s current location: SIP address

[email protected]) The Proxy server decides to proxy the call and creates a new INVITE message

based on the original INVITE message, but with the request URI in the start line changed to [email protected]. The Proxy server sends this request to the UAS at lab.acme.com.


Call Proxying contd ..

6) The UAS responds first with a 100 (Trying).7) The UAS responds with a 180 (Ringing) response.8) The Proxy server forwards the 180 (Ringing) response back to the calling UA.9) When the call is accepted by the user (for example, by picking up the handset) the

UAS at lab.acme.com sends a 200 (OK) response. In thi sexample, Bob’s UAS inserts a Contact header into the response with the value [email protected]. Further SIP communication will be sent directly to it and not via the Proxy Server. This action is optional.

10) The Proxy forwards the 200 (OK) response back to the calling UAC.11) The calling UA sends an ACK directly to Bob’s UA at the lab (according to the

Contact header it found in the 200 (OK) response).


Call Proxying


Services provided by SIP SIP provides the necessary protocol mechanisms so that end systems and

proxy servers can provide following 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.


Services provided by 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 Back-To-Back User Agent A SIP Back-To-Back User Agent (B2BUA) : takes what is traditionally a SIP

end-to-end call and mediates it through a central SIP server. The B2BUA enables service providers to manage and track a call from beginning to end.

The SIP standard briefly defines a B2BUA as a logical entity that receives requests as a User Agent Server (UAS) and in order to respond to them, it acts as a User Agent Client (UAC) and generates requests.

It maintains dialog state and must participate in all of the requests sent on the dialogs it has established. The standard defines it as a concatenation of a UAC and UAS.


Issues in B2BUA functionality The B2BUA functionality breaks one of SIP's advantages of end-to-end service

because it prevents a UA to directly contact the destination UA by mediating the call between them. This prevents direct implementation of features such as REFER and exchange of secured bodies using S/MIME. Therefore a B2BUA should be used only in cases where such mediation is required/desired, usually when central call control is required.

This B2BUA functionality provides major new applications including: centralized call management interworking with alternative networks SIP--based VoIP interworking between LAN and WAN management and monitoring of the entire call state cloaking of endpoint location.


B2BUA functionality

Basic B2BUA functionality Third Party Call Control


Quality Of Service (QoS)

One of the most vexing problem for the SIP protocol designers. Addresses the areas of jitter and latency of packet delivery within

the Internet. For critical applications such as VoIP, QoS is of critical importance

since the human ear is extremely sensitive to latency in the delivery of sound. It can detect delays of 200 msec or greater in voice conversations.


Quality Of Service (QoS)

To create QoS on the Internet, you must create different classes of service for packets with different contents.

The IETF has taken two approaches:

1. Integrated Services (RFC2211 and RFC2212) also known as INTSERV.

2. Differentiated Services (RFC2475), or DIFFSERV.


Quality Of Service - INTSERV INTSERV essentially creates an end-to-end private lane for packet

voice traffic that is opened and monitored by each router along the path and the endpoints. No packets are sent out unless the entire route signals its ability to meet and guarantee the service requirements for the call. The protocol used to reserve the resources in the network, and get confirmation of those resources, is known as RSVP, or the Resource Reservation Protocol (RFC-2205).


Quality Of Service - DIFFSERV

DIFFSERV creates classes of service, and controls the admission of that traffic onto the Internet, by filtering packets at the edge of the network. Here, there are no explicit requests for resources from the network. The advantage to the DIFFSERV approach is that it does not require the maintenance of network state by all elements, and thus scales better than RSVP.


Quality Of Service contd.. Clearly, the INTSERV approach offers the highest level of quality for

sensitive applications, such as voice. For SIP, this means the transparent integration of two forms of signaling :

Signaling to set up the call (using SIP) Setting up QoS using RSVP

Such seperation can have interesting side-effects, such as one might succeed (call setup) and the other fail (resource reservation). So the phone rings and gets answered even though the network cannot support th call.


Quality Of Service contd.. To handle such a problem, a coupling mechanism was developed. The coupling allows the SIP INVITE , (that is the SDP), to contain indicators

that tell the called user not to "ring the phone" until sufficient resources have been reserved (using RSVP or some other mechanism).Once the reservations have succeeded, the caller sends a new request, tentatively dubbed "PRECONDITIONS_MET," to the called user, indicating that resources are available, and the phone should ring. But if the QoS reservation fails, the call can optionally proceed with best effort


Challenges for SIP Even with the potential that SIP offers there are many drawbacks, such as Interoperability : A critically important topic which has not yet been finalized

and even though there was a great deal of improvement in this respect, there is still a long way to go.

Network Address Translation (NAT): NATs provide a boundary between the private IP addressing of a network and the public Internet. Hence SIP which fundamentally, is a control channel for establishing sessions can cause problems for NATs since the addresses for the established sessions are in the body of the application layer messages.


Challenges for SIP

FIREWALLS : When a user inside the firewall sends media to an address outside the firewall, it will be dropped by the firewall unless a rule is established to allow it to pass. Since the media is sent on dynamic ports to dynamic addresses, these rules must be dynamically installed through application-aware devices, such as proxies.

Voice over IP

John P John

CS01B012


What is VoIP? VoIP : Voice over Internet Protocol is also referred to as IP Telephony.

VoIP involves sending voice transmissions as data packets using the Internet Protocol(IP).

The users voice (or fax) is converted into a digital signal, compressed, and broken down into a series of packets.


What is VoIP?

The packets are then transported over private or public IP networks and reassembled and decoded on the receiving side.

At the receiving end, the re-assembled packets arrive as a normal sounding voice call. FIG


Origins: In 1995, Vocaltec produced the first commercially available VoIP product for

PC-to-PC voice chat over the internet.

Today, the scope of VoIP is not restricted to only transmission of audio signals.

It can be used for multi-party conferencing, video and fax transmissions as well.


Why VoIP? The PSTN has been operating successfully for over a hundred years. Why

then do we need a new technology like VoIP?

One of the main motivations for VoIP is the low cost involved. For example, international calls can be routed to its destination country, through the Internet, thus saving on PSTN bills.

Distance is not a concern for billing, unlike PSTN.


Major Concerns Quality of Voice Since it was designed for data, IP does not provide real time guarantees,

but only provides a best-effort service.

Packets can be lost or may arrive out of order. For VoIP to be acceptable to users, the delay also has to be below a threshold value.

Various protocols like RTP, RTCP have been devised to tackle these problems.


Major Concerns Integration with the PSTN: PSTN will remain a major player in the telephone industry and so VoIP

should be able to work in conjunction with with the PSTN.

Security: Since the voice data is being transmitted over the public Internet, privacy is

an important issue.

VoIP must provide methods to encrypt the call and perform authentication and admission control.


Making a Call: Making a call using VoIP is quite similar to making one on PSTN.

The following are the main steps involved:

1. Caller picks up the handset and hears a dial-tone.

2. The caller dials the telephone number, which will be mapped to the IP Address of the callee.


Making a Call: 3. Call setup protocols are used to locate the callee and seng a signal to

produce a ring.

4. The callee picks up his handset and begins the conversation. The audio signals are encoded using a codec and the resulting packets are transmitted over the IP network.

5. Conversation ends, the connection is terminated and billed.


Codecs Typically, the voice-coding algorithm used for an IP telephony or VoIP

network in a LAN environment is G.711, which divides a voice stream up into 64 Kbps packet increments. It is regarded as toll quality.

Some of the other more widely available voice coding algorithms/compressors on the market are the G.729a and G.723 codecs.

The G.729a and G.723 codecs are normally used for WAN connections where bandwidth is at a premium and voice compression is a requirement.


Codecs

The majority of vendors who support IP telephony recommend the G.729a codec due to its superior quality over G.723, making it the de facto standard for WAN connections running IP telephony.

A summary of the codecs is given below:

G.711 64 kbps PCM

G.721 32 kbps ADPCM

G.728 16 kbps CELP

G.729 8 kbps CS-ACELP


The H.323 Standard This is the ITU’s standard that vendors should comply while providing Voice

over IP service. It was originally developed for multimedia conferencing on LANs, but was later extended to cover Voice over IP.

The standard encompasses both point to point communications and multipoint conferences.

H.323 is considered an “umbrella protocol” because it defines all aspects of call transmission, from call establishment to capabilities exchange to network resource availability.


H.323 Components The H.323 standard specifies four logical components,which when

together provide point-to-point and multi-point multimedia communication services.

These components are:

1. Terminals2. Gateways3. Gatekeepers4. Multipoint Control Units (MCUs)


H.323 Components

Terminals: Terminals are the client endpoints on the LAN that provide real-time, two-

way communications. All terminals must support voice communications; video and data are optional.

A terminal may be a personal computer or any other device running H.323. A H.323 terminal can communicate with either another H.323 terminal, a

H.323 gateway or a MCU.


Gateways

Gateways: A gateway is used to connect two dissimilar networks.

It preforms the function of a translator, converting between different formats, e.g: connecting an IP network with the PSTN.

The gateway translates betweent various protocols in a transparent fashion. It may also provide facilities for audio/video format conversion if they differ at the two ends.


Gatekeepers

A Gatekeeper is the most important component of an H.323 enabled network. It acts as the central point for all calls within its zone and provides call control services to registered endpoints.


Gatekeepers

A gatekeeper provides services like:

Address Translation Authorization( admission control ) Bandwidth control Accounting & Billing Call routing


Multipoint Control Unit (MCU) MCUs provide support for conferences between 3 or more H.323 terminals.

All terminals wishing to participate in a conference must establish a connection with the MCU, which manages the conference resources and media streams.

It is also responsible for negotiating the audio/video codecs to be used for the conference.


H.323 Protocols H.323 specifies the following protocols:

H.225 Registration, Admission, Status(RAS) H.225 Call Signaling H.245 Control Signalling

The packetized voice signals are finally sent over the network using RTP(real-time transfer protocol) or RTCP(real-time transport control protocol).


H.323


Session Initiation Protocol ( SIP ) This is the IETF’s standard for establishing VOIP connections. It is an

application layer control protocol for creating, modifying and terminating sessions with one or more participants.

As a protocol, SIP only defines how sessions are to be set up and torn down.

It utilizes other IETF protocols to define other aspects of VoIP sessions, such as SDP for capabilities exchange, URIs for addressing, DNS for service location, and Telephony Routing over IP (TRIP) for call routing.


SIP Components The SIP System consists ot two components:

User Agents: A user agent is an end system acting on behalf of a user. There are two parts to it – the User Agent Client (UAC) and the User Agent

Server (UAS). The UAC is used to initiate an SIP request while the UAS is used to receive

requests and return responses on behalf of the user.


SIP Components Network Servers: There are 3 types of servers within a network.

A registration server receives updates concerning the current locations of users.

A proxy server on receiving requests, forwards them to the next-hop server, which has more information about the location of the called party.

A redirect server on receiving requests, determines the next-hop server and returns the address of the next-hop server to the client instead of forwarding the request.


SIP Session Establishment


QoS in VoIP Quality of Service is essential for the success of VoIP.

The human ear is extremely sensitive to even minor changes in an audio signal.

Loss of quality occurs when the voice packets are transferred over the inherently unreliable packet-based networks.

Delays, jitter, lost packets and out-of-sequence packets are the main factors responsible for the poor quality.


QoS in VoIP Some methods to enhance the QoS achieved in VoIP are:

Classification of Service: Using the TOS bits in the IP header to set a priority for the voice packet.

MPLS: Tagging the packets with labels and using the labels to decide the route. Voice packets can be routed over less congested networks.

RSVP: Reserving resources to meet requirements for bandwidth, delay, jitter, etc. along a particular path through a series of routers.


References: “Packet-based multimedia communications systems” ITU-T Recommendation H.323

“IP Telephony – a high level overview” www.bitpipe.com

Upkar Varshney, Andy Snow, Matt McGivern, and Christi Howard – “Voice over IP” – Vol 25 , No I, Communications of the ACM

SIP – Protocol Overview, white paper RADVISON

The Session Initiation Protocol(SIP) – Henning Schulrinne


References (…contd) Understanding Packet Voice Protocols – white paper, Cisco Systems

Voice over IP – Protocols and Standards, http://www.cis.ohio-state.edu/~jain/cis788-99/voip_protocols/index.html

IP Telephony Design Guide – white paper, Alcatel

A Primer on the H.323 series standard , http://www.packetizer.com/iptel/h323/papers/primer/

Tutorials, www.serverwatch.com

RFC 3261 – Session Initiation Protocol (SIP)


Resource reSerVation Protocol

Inadequacies of point to point best effort service. Resource Reservation, multicasting and QOS. Resource reSerVation Protocol. A RSVP Example.


RSVP Protocol Mechanisms Policy Control and Security RSVP Paradigm.


Inadequacies of point to point best effort service

This primitive model is inadequate for distributed applications such as remote video, multimedia conferencing, data fusion and other real time constrained applications.

Many of these applications are very sensitive to the quality of service their packets receive. For a network to deliver the appropriate guaranteed QOS it must go beyond the best-effort service model and


allow flows to reserve network resources. Also these applications are not solely point to point, they

are often multipoint-to-multipoint. It is rather inefficient to incorporate multicasting in point

to point model, for eg., in case of three receivers the sender has to replicate the data streams on his bandwidth for each receiver.


There is a need for new network architecture and service models to accommodate these new application requirements.

Without rigor any architecture capable of accomadating multicast and a variety of qualities of service can be divided into the following distinct components:


A.Flow Specification

B.Routing.

C.Resource Reservation

D.Admission Control


Resource Reservation, multicasting and QOS

For a network to deliver a quantitatively specified quality of service to a particular flow, it is usually necessary to set aside certain resources.

This becomes more relevant in multicasting. With resource reservation instead of sender having to

replicate data on it’s bandwidth the routers and switches can replicate the data for different receivers.


Resource reSerVation Protocol

One solution that can handle this environment is the RSVP protocol.

The simplest form of this protocol is set to achieve the following goals:

– 1.To provide for heterogeneous receivers to make reservations specifically tailored for their needs.

– 2.Adapt to changing muticast group membership.


– 3.Optimize bandwidth uses and eliminate congestion.– 4.Allow receivers to switch channels.– 5.Adapt to changes in the underlying unicast and

multicast routes.– 6.Control protocol overhead so that it does not grow

linearly with the number of participants and hence scalability.

– 7.Modularity to accommodate heterogeneous underlying networks.


A RSVP Example

In its simplest form, the protocol uses multicast routing using spanning trees.

Each group is assigned a group address. The standard multicast routing algorithm then builds a spanning tree covering all group members.

The routing algorithm is independent of RSVP.


Sender advertises PATH messages to receiver PATH = TSpec + AdSpec

TSpec: Specify the traffic characteristics AdSpec:

Contain information about the path’s resources

Updated in every RSVP capable router Help receivers calculate the resources

needed to obtain desired QoS


Any of the receivers can send a reservation message up the tree to the sender. RESV = Rspec + filterspec + policy data

Rspec: Specify the bandwidth needed Filterspec:How reservations are distributed to data

streams and users. Travel upstream in reverse direction of Path message Routers receive the RESV messages and make the reservation

(if available resources are more than Rspec resources)


RSVP Protocol Mechanisms

1.RSVP messages: There are two fundamental RSVP message types:

Resv and Path. Each receiver host sends RSVP reservation request

(Resv) message upwards towards the senders. These messages must follow exactly the reverse of the path(s) the data packets will use, upstream to all the sender hosts included


in the sender selection. They create and maintain ‘reservation state’ in each node along the path(s).

Path messages are sent with the same source and destination addresses as the data, so that they will be routed correctly. On the other hand, Resv messages are sent hop-by-hop;each RSVP-speaking node forwards a Resv message to the


unicast address of a previous RSVP hop. 2.Merging Flowspecs

A Resv message forwarded to a previous hop carries a flowspec that is the ‘largest’ of the flowspecs requested by the next hops to which the data flow will be sent. We say the flowspecs have been ‘merged’.


3.Soft State RSVP takes a ‘soft state’ approach to managing the reservation

state in routers and hosts. RSVP soft state is created and periodically refreshed by path and Resv messages. The state is deleted if no matching refresh messages arrive before the expiration of a ‘cleanup timeout’ interval.


4.Teardown RSVP ‘teardown’ messages remove path or reservation state

immediately. Although it is not necessary to explicitly tear down an old reservation, it is better that all hosts send a teardown request as soon as an application finishes.


5.Confirmation To request a confirmation for its reservation request, a receiver

Rj includes in the Resv message a confirmation-request object containing Rj’s IP address. At each merge point, only the largest flowspec and any accompanying confirmation-request object is forwarded upstream.


Policy control and security

RSVP-mediated QoS requests allow particular user(s) to obtain preferential access to network resources. To prevent abuse, some form of back pressure will generally be required on users who make reservations. For example, such back pressure may be accomplished by administrative access policies.


“Are enough resources available to meet this request” and “Is this user allowed to make this reservation?” these two decisions could be considered under ‘admission control’ decision and the ‘policy control’ decisions, respectively.


RSVP raises the following security issues. Message integrity and node authentication.

Corrupted or spoofed reservation requests could lead to theft of service by unauthorized parties or to denial of service caused by locking up network resources.

User authenticationPolicy control will depend upon positive authentication of the user responsible for each reservation request.


Secure data streamsThe above security issues concerned RSVP’s operation. A third security issue concerns resource reservations for secure data streams. This arises if the transport and higher level headers are encrypted.


5.RSVP Paradigm

RSVP is not a routing algorithm or a part of it. All protocols(they have to be different from IP and other

point to point network protocols) aiming to providing for the requirements of the distributed multimedia applications shall be classified to belong to this paradigm if they have the following properties:


receiver oriented resource reservation

allow receivers to make heterogeneous reservations.

Providing different reservation styles separating reservation from filtering

and other routing policies protocol overhead control


maintaining ‘softstate’ in the network modularity (most importantly)guaranteed

provision of quantitatively specified QOS.


Consistent with the above classification, we can have solutions to the distributed multimedia applications and other problems over mobile networks in RSVP paradigm.

Various protocols can be now designed to be tailor made for demands specifying reservation mechanisms, multiplexing, scalability, integration with other protocols,


dynamic resource sharing, Integrating routing and reservation mechanisms.References to specific works in this direction are cited in the end.

References: A resource reservation protocol in wireless mobile networks,

Parallel Processiong Workshops, 2001. International Conference 7 Sept.2001


RSVP and Q.2931Signalling for Broadband, IEE Tutorial Colloquium on, 14 Dec 1995

RSVP: a new resource ReSerVation ProtocolNetwork, IEEE , Volume: 7 Issue:5, Sept.1993

Integrating routing and resource reservation mechanism in real-time multicast protocolsDistrubuted Computing Systems, 1996., Proceedings of the 16th International Conference on, 27-30 May 1996


Network Working Group, RFC:2205 Computer Networks

Andrew S Tanenbaum

STREAMING PROTOCOLS

- Kaustubh Nyalkalkar

(CS01 B038)


An Overview

The Web has grown from a hypertext system to a hypermedia system.

To access media files, download them and play them. But, this requires both time and space.

Alternatively, stream the file over the network, and play as received. This requires the use of streaming protocols.


Streaming

On receiving a request for a file, the media server splits the file into smaller packets.

Packets are sent according to the streaming protocols. Client-side streaming media application buffers the

incoming packets until a certain amount is received; then starts playing.

For a good network connection, no perceivable delay in data delivery.


The Protocols Needed…

Stream description: SDP, SMIL Describe the session and content.

Stream control: RTSP Remote control the session.

Media transport: RTP/RTCP Send the data.

Resource reservation: RSVP Makes sure the communication path offers appropriate

guarantees; else best effort transmissions.


Components and Protocols

StreamDescrpn.

ClientMedia Source

RTP

RTSP

RTCP

SDP

REAL TIME STREAMING PROTOCOL


Introduction

RTSP is an application-level protocol for control over the delivery of data with real-time properties.

Sources of data may be live data feeds or stored clips. Intends to control multiple data delivery sessions, to

provide a means of choosing delivery channels (like UDP or TCP) and to provide a means of choosing delivery mechanisms based upon RTP.


Terminology Aggregate control:

The control of multiple streams using a single timeline by the server.

Single play message for both audio and video streams. Continuous media:

Data where the timing relationship that existed at the source must be reproduced at the sink.

Media server: The server providing playback and/or recording services for one

or more media streams.


Terminology (..contd)

Presentation: A set of one or more media streams presented to the client as a

complete media feed, using a presentation description. The streams may be aggregate controlled.

Presentation description: It contains information about one or more media streams within a

presentation, such as the set of encodings, network addresses and information about the content.

Done in several formats, like SDP.


Terminology (..contd)

RTSP session: A complete RTSP transaction; e.g.: the viewing of a movie. A

session typically consists of a client setting up a transport mechanism for the continuous media stream (SETUP), starting the stream with PLAY or RECORD and closing the stream with TEARDOWN.


Overview of RTSP

Establishes and controls either a single or several time-synchronized streams of continuous media.

Typically, doesn’t deliver the streams itself; although the streaming media streams and the control streams can be interleaved.

Acts as a ‘network remote control’ for the media servers.


Overview of RTSP(..contd.)

No notion of RTSP connection; server maintains an identifier for each session.

An RTSP session is independent of the transport-level connection.

During a session, client may open and close many transport level connections to server. Alternatively, a connectionless transport protocol may be used.

Also independent of the transport mechanism used to carry the continuous media.


RTSP and HTTP

Intentionally similar in syntax to HTTP. Any future extensions to HTTP can easily be added to RTSP

too, with little or no modification. Can be parsed easily by standard HTTP parsers. Can adopt HTTP’s work on web security mechanisms, caches

and proxies. The older version of HTTP did not support real-time data. So,

RTSP offers HTTP level-services for real-time data.

Yet differs from HTTP in several areas.


Differences

An RTSP server has to maintain state by default. HTTP is stateless.

Data will be delivered even if no RTSP command is received in a long time. To handle multiple sessions, need to maintain session state of client, like PLAY, SETUP, TEARDOWN etc.

Both the server and client can issue RTSP requests. HTTP is asymmetric; client requests, server responds.

Mostly, data is carried ‘out of band’, by a different protocol.


Supported Operations

Retrieval of media from a media server. Client can request presentation description via HTTP, say. For multicast presentation, the description contains the

multicast addresses and ports to be used. For unicast, the client provides the destination.

Invitation of a media server to a conference. To playback or record all or a subset of the media in the

presentation.

Addition of media to an existing presentation. Helpful for live presentations; can tell client about additional

media becoming available.


Properties of RTSP

Extendable Text-based Easy to parse Secure (re-uses web security mechanisms) Transport independent Multi-server capable Control of recording devices


Properties of RTSP (..contd.)

Separation of stream control and conference initiation Only requirement is that the conference initiation protocol

either provides or can be used to create a unique conference identifier.

SIP can be used to invite a server to a conference.

Presentation description neutral Presentation description must contain at least one RTSP

URL.

HTTP friendly


Properties of RTSP (..contd.)

Transport negotiation The client can negotiate the transport method prior to

actually needing to process a continuous media stream.

Capability negotiation If some basic features are not supported, the client must

know which methods are not going to supported, so that it can create an appropriate user interface.

Appropriate server control If the client can start a stream, then it must also be able to

stop it.


Overall Operation

Each presentation and media stream may be identified by an RTSP URL.

The presentation description file containing a description of the media streams making up the presentation, including their encodings, language, and other parameters, is obtained by the client, via HTTP, email etc.

Using this file, the client chooses the most appropriate mix of media and the transport method for them.


Overall Operation (..contd.)

The network address and the port are determined by the server depending on the mode of operation.

Unicast: Media is transmitted to the source of RTSP request with

the port no. chosen by the client or on the same reliable stream as RTSP.

Multicast, the server chooses the addresses. Multicast, the client chooses the address.


RTSP URLs

rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]

URLs may refer to a stream or an aggregrate of streams i.e. a presentation.

Resource is controlled by RTSP at server listening for TCP connections/UDP packets.

Eg rtsp://media.example.com:554/twister/audiotrack rtspu://media.example.com:554/twister


RTSP Methods

Major methods SETUP: server allocates resources for a

stream and starts an RTSP session;

also specifies transport mechanism. PLAY: starts data tx on a stream PAUSE: temporarily halts a stream TEARDOWN: frees resources of the stream, no

RTSP session on server any more


RTSP Methods (..contd.)

Additional methods OPTIONS: get available methods ANNOUNCE: change description of media object DESCRIBE: get low level descr. of media object RECORD: server starts recording a stream REDIRECT: redirect client to new server SET_PARAMETER: device or encoding control GET_PARAMETER:retrieve parameter value of

stream or presentation


Example

clientC

web server

W

mediaserversA & V

HTTP GET

presentation description (sdp)

SETUP

PLAY

RTP audio/video

RTCP

TEARDOWN


Example(..contd.)

HTML page, RAM page (both on web server) and Real Audio/Media (.ra, .rm) file (on media server).

HTML page contains link to the RAM file. RAM file contains links to the .ra or .rm file. It is the

presentation description.

REAL TIME TRANSPORT PROTOCOL

& REAL TIME CONTROL

PROTOCOL


Overview of RTP

A transport protocol for data with real-time characteristics.

Often transported in UDP/IP. Does not define any QoS mechanism for real-time

delivery. Multicast friendly. Many encoding possibilities. RTP mixers: many streams to one. RTP translators: media format conversion.


RTP Functions

Sequencing (loss & reorder detection) Intramedia synchronization (timestamps; remove jitters

with playout buffers) Intermedia synchronization (lip-synch between audio and

video) Frame indication (e.g: Synchronized data delivery to

higher layers) Source identification (Multicast support)


Overview of RTCP

Companion protocol of RTP. It too does not guarantee any QoS for real-time delivery. Carrier of control information. Periodic transmission of control packets.


RTCP Functions

Provides feedback on the quality of data distribution (packet loss, jitter).

Helps to localize networks problems. Lets everybody evaluate the no. of participants. Carries a persistent transport level canonical name for a

source, CNAME.


RTCP Generalities

Distribution: Uses same distribution mechanisms as data packets

(n m multicast). Multiple RTCP packets can be concatenated by

translators/mixers to give a compound RTCP packet.

Scalability with session size: RTCP traffic should not extend 5% of the total session

bandwidth. Requires an evaluation of the no. of participants.

At least 25% of the bandwidth is for source reports. Lets every user quickly know the CNAME of sources.


RTCP Generalities (..contd.)

Five RTCP packets SR sender reports tx and rx statistics from active

senders RR receiver reports rx statistics from other

participants, or from active senders if more than 31 sources

SDES source description, including CNAME BYE explicit leave APP application specific extensions


REFERENCES

RFC 2326 – Real Time Streaming Protocol (RTSP) RTP/RTCP, RTSP, and RSVP

Multimedia protocols for the Internet - Jim Chou and Thinh Nguyen

Real Time Protocols – Tarik Cicic

SESSION INITIATION PROTOCOL

Documents

Transcript of SESSION INITIATION PROTOCOL