Voice over IP The protocol specification
#1

[attachment=389]
Presented by:Girish R
Voice over IP The protocol specification


Abstract
IP telephony, known in the industry as Voice-over IP (VoIP), is the transmission of tele-phone calls over a data network like one of the many networks that make up the Internet. VoIP involves sending voice transmissions as data packets using the Internet Protocol (IP). In VoIP, user's voice is converted into digital signal, compressed and broken down into a series of packets. The packets are then transported through a public or private network and are reassembled and decoded at the receiver. Just as conventional telephony, VoIP needs a connection between the users (virtual connection). VoIP architecture involves too many protocols. First a signaling protocol is needed to setup individual sessions for voice connections between users. Once a session is established, a transport protocol can be used to send data packets. Directory access protocols provide routing and switching informa¬tion for connecting calls. Two standards have recently emerged for signaling and control for Internet Telephony. One is ITU Recommendation H.323, and the other is the IETF Session Initiation Protocol (SIP). These two protocols represent very different approaches to the same problem: H.323 embraces the more traditional circuit-switched approach to signaling based on the ISDN Q.931 protocol and earlier H-series recommendations, and SIP favors the more lightweight Internet approach based on HTTP.


Introduction
Internet telephony refers to communication services - voice and voice messaging applications-that are transported via the internet rather than the public switched telephone network(PSTN). The basic steps involved in originating an internet telephone call are conversion of the analog voice signal to digital format and compression and translation of the signal into IP packets for transmission over the internet; the process is reversed at the receiving end. The possibility of voice communications travelling rather than the PSTN, first became a reality in 1995 when Vocaltec.Inc. introduced its internet phone software. Designed to run on a 486/33Mhtz (or higher) personal computer equipped with a sound card, speakers, microphone and modem, the software compresses the voice signal and translates it into IP packets for transmission over the internet. This PC-to-PC internet telephony works only if both parties are using internet phone software.
In a relatively short period of time since then, internet telephony has advanced rapidly. Gateway servers are emerging to act as an interface between the Internet and the PSTN. These Gateway servers enable users to communicate via standard telephones.

1.1 Circuit Switching
Circuit switching is the concept that has been used by the telephone networks for many years. When a call is made between two parties, connection is maintained for the entire duration of call. The two points are connected in both directions, hence called a circuit. Here's how a typical telephone call works Let 'A' wants to make a call to 'B'
• 'A' picks up the receiver and listen for a dial tone.
• 'A' dials the number of 'B'.
• The call is routed through the switch at A's local carrier to 'B'.
• A connection is made between A's telephone and the B's telephone, opening the circuit.
• 'A' talks for a period of time and then hangs up the receiver.
• When 'A' hangs up, the circuit is closed, freeing the line.
Let's say 'A' talks for 10 minutes. During this time, the circuit is continuously open between the two phones. Telephone conversations over the traditional PSTN are transmitted at a fixed rate of about 64 kilobits per second (Kbps), or 1,024 bits per second (bps), in each direction, for a total transmission rate of 128 Kbps or 16 kilobytes per second (KBps) and 960 KB every minute it's open. So in a 10-minute conversation, the total transmission is 9600 KB, which is roughly equal to 9.4 megabytes (MB).

In a typical phone conversation, much of this transmitted data is wasted. While 'A' is talking, 'B' is listening, which means that only half of the connection is in use at any given time. More¬over a significant amount of the time in most conversations is dead air - neither party is talking. If we could remove these silent intervals, the file would be even smaller. Data networks do not use circuit switching. The Internet connection would be a lot slower if it maintained a constant connection to the web page that we are looking at. Instead of simply sending and retrieving data as needed, the two computers involved in the connection would pass data back and forth the whole time, whether the data was useful or not. That's not an efficient data network.
The fundamental problem with the existing telephone networks is that they rely on circuit switching. Instead, data networks use a method called packet switching.

1.2 Packet Switching
In packet switching connection is opened just to send a small chunk of data (packet) from one system to another. The sending computer chops data into small packets, with an address on each one telling the network where to send them. When the receiving computer gets the packets, it reassembles them into the original data.

Packet switching is very efficient. It minimizes the time that a connection is maintained be-tween two systems, which reduces the load on the network. It also frees up the two computers communicating with each other so that they can accept information from other computers as well. Packet switching allows several telephone calls to occupy the amount of space occupied by one in a circuit-switched network.

VoIP technology uses packet-switching method. Using PSTN, that 10-minute phone call con¬sumed 10 full minutes of transmission time at a cost of 128 Kbps. With VoIP, that same call may have occupied only 3.5 minutes of transmission time at a cost of 64 Kbps, leaving another 64 Kbps free for that 3.5 minutes, plus an additional 128 Kbps for the remaining 6.5 minutes. Here's how a typical telephone call using VoIP over a packet-switched network works Let 'A' wants to make a call to 'B'
• 'A' picks up the receiver, which sends a signal to the PBX (Private Branch Exchange acts as a gateway).
• The PBX receives the signal and sends a dial tone.
• 'A' dials the number of 'B'. This number is then temporarily stored by the PBX.
• Once the number is entered, the PBX checks it to ensure that it is in a valid format.
• The PBX determines whom to map the number to. In mapping, the number is attached to the IP address of another device called the IP host. The IP host is typically another digital PBX that is connected directly to the phone system of 'B'.
• 'A' session is established between A's PBX and the B's IP host. This means that each system knows to expect packets of data from the other system. Each system must use the same protocol to communicate. The systems will implement two channels, one for each direction, as part of the session.
• 'A' talks for a period of time. During the conversation, A's PBX and the B's IP host transmit packets back and forth when there is data to be sent. The PBX at A's end keeps the circuit open between itself and A's phone extension while it forwards packets to and from the IP host at the other end.
• 'A' finishes talking and hang up the receiver.
• When 'A' hangs up, the circuit is closed between the phone and the PBX.
• The PBX sends a signal to the IP host of 'B' that it is terminating the session. The IP host terminates the session at its end, too.
• Once the session is terminated, the PBX removes the number-to-IP-host mapping from memory.
2 VoIP Protocols

2.1 What Protocols are needed?

Protocols needed Function Protocols available
Signalling protocol To establish presence,locate users, set up, modify and tear down sessions SlP/SDP(lblP) H.323{ITU-T)
Media Transport Protocols For transmission of packetized audio/video Media: RTP Transport UDP.TCP
Supporting Protocols Gateway Location, QoS, address translation, IP etc DNS.RSVPetc

2.2 Session initiation protocol (SIP)
SIP is a simple, ASCII-based protocol. This is the IETF (Internet Engineering Task Force) standard for establishing VoIP connections. It is an application layer control protocol (defined in RFC 2543) for creating, modifying and terminating sessions with one or more participants. The architecture of SIP is similar to that of HTTP (client server protocol). Requests are generated by the client and send to the server. The server processes the request and then sends a response to the client. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response.

2.2.1 Components of SIP
SIP is a peer-to-peer protocol. The peers in a session are called User Agents (UAs). A user agent can function in one of the following roles
• User agent client (UAC) - The client application that initiates and sends SIP requests.
• User agent server (UAS) - The server application that contacts the user when an SIP request is received and that returns a response on behalf of the user.
From an architecture standpoint the physical components of a SIP network can be grouped into two categories: clients and servers. SIP Clients
• Phones - Can act as either a UAS or UAC. eg: Softphones (PCs that have phone capabil¬ities installed).
• Gateways - Provide call control. Gateways provide many services, the most common being a translation function between SIP conferencing endpoints and other terminal types. This function includes translation between transmission formats and between communication procedures. In addition, the Gateway translates between audio and video codecs and performs call setup and clearing on both the LAN side and the circuit switched network side.
SIP Servers
SIP servers include:
• Proxy server
The proxy server is an intermediate device that receives SIP requests from a client and then forwards the requests on the clients behalf. Basically, proxy servers receive SIP messages and forward them to the next SIP server in the network. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission and security.
• Redirect server
Provides the client with information about the next hop or hops that a message should take and then the client contacts the next hop server or UAS directly.
• Registrar server
Processes requests from UACs for registration of their current location. Registrar servers are often co-located with a redirect or proxy server.

2.2.2 SIP Messages
SIP messages are used for communicating between the client and the SIP server. The messages are:
INVITE: For inviting a user to a call.
BYE: For terminating a connection between the two end points.
ACK: For reliable exchange of invitation messages.
OPTIONS: For getting information about the capabilities of a call.
REGISTER: Gives information about the location of a user to the SIP registration server. CANCEL: For terminating the search for a user.

2.2.3 How SIP works?
Users in a SIP network are identified by unique SIP addresses. When making a SIP call, a caller first needs to locate the appropriate server and send it a request. The caller can either directly reach the callee or indirectly through the redirect servers. The Call ID field in the SIP message header uniquely identifies the calls.
• SIP Addressing
SIP URL has a similar form to an email address, typically containing a username and a host name. SIP URL is of the form sip:username@host. A SIP address can either designate an individual or a whole group.
• Locating a SIP server
The client can either send the request to a SIP proxy server or it can send it directly to the IP address and port corresponding to the Uniform Request Identifier (URL).
• SIP Transaction
Once the host part of the Request URL has been resolved to a SIP server, the client can send requests to that server. A request together with the responses triggered by that request makes up a SIP transaction. The requests can be sent through reliable TCP or through unreliable UDP.
• SIP Invitation
A successful SIP invitation consists of two requests: a INVITE followed by ACK. The INVITE request asks the callee to join a particular conference or establish a two party conversation. After the callee has agreed to participate in the call, the caller confirms that it has received that response by sending an ACK request. The INVITE request contains a session description that provides the called party with enough information to join the session. If the callee wishes to accept the call, it responds to the invitation by returning a similar session description.
• Locating a User
A callee may keep changing its position with time. These locations can be dynamically registered with the SIP server. When the SIP server is queried about the location of a callee, it returns a list of possible locations. A Location Server in the SIP system actually generates the list and passes it to the SIP server.
• Changing an Existing Session
Sometimes we may need to change the parameters of an existing session. This is done by re-issuing the INVITE message using the same Call ID but a new body to convey the new information.

2.2.4 SIP operation using a proxy server
Request and Response
If a proxy server is used, the caller UA sends an INVITE request to the proxy server, the proxy server determines the path, and then forwards the request to the callee. The callee responds to the proxy server, which in turn, forwards the response to the caller (200 OK) (as shown in figure below).

between the caller and callee. Real-time Transfer Protocol (RTP) is used for the communication between the caller and the callee (as shown in figure below).

2.2.5 SIP operation using a redirect server
If a redirect server is used, the caller UA sends an INVITE request to the redirect server, the redirect server contacts the location server to determine the path to the callee, and then the redirect server sends that information back to the caller. The caller then acknowledges receipt of the information (as shown in figure below).

The caller then sends a request to the device indicated in the redirection information (which could be the callee or another server that will forward the request). Once the request reaches the callee, it sends back a response and the caller acknowledges the response. RTP is used for the communication between the caller and the callee (as shown in figure below).

2.2.6 Sample SIP operation
Heres a typical example of a SIP message exchange between two users, Alice and Bob. In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment.

Alice "calls" Bob using his SIP URL. In this case, it is sip:bob[at]biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URL of sip:alice[at]atlanta.com. Alice might have typed in Bob's URL or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URL, called a SIPS URL. An example would be sips:bob[at]biloxi.com. A call made to a SIPS URL guarantees that secure, encrypted transport is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee.

In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URL. INVITE is the SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destina¬tion address, Alice's address, and information about the type of session that Alice wishes to

establish with Bob.


Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE requesd to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP.

The atlanta.com SIP server is a type of SIP server known as a proxy server. The proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is work¬ing on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq (sequence number) and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. As a result, it obtains the IP address of the biloxi.com proxy server and forwards or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the
INVITE and is processing the request. The proxy server consults a database, generically called a location service that contains the current IP address of Bob. The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone.

Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being maintained in the proxies. This also has the de¬sirable property that each proxy that sees the INVITE will also see all responses to the INVITE.

When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ring back tone or by displaying a message on Alice's screen. In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to es¬tablish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages.
Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: voice over ip security, atlanta braves 2006, voice over ip australia, ssrs report specification, bob clerk**vel agency project in php, specification of dpc ppt, zigbee specification,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  AN EXTENDED ZONE ROUTING PROTOCOL FOR SERVICE DISCOVERY IN MOBILE AD HOC NETWORKS seminar presentation 1 9,306 24-12-2012, 12:47 PM
Last Post: seminar details
  Enhanced QoS Multicast Routing Protocol nit_cal 1 5,704 20-12-2012, 10:31 AM
Last Post: seminar details
  Distributed Cache Updating for the Dynamic Source Routing Protocol seminar class 3 2,286 17-11-2012, 01:26 PM
Last Post: seminar details
  Secure access system using signature verification over tablet PC project topics 1 1,766 24-10-2012, 01:27 PM
Last Post: seminar details
  Simple Network Management Protocol SNMP project report tiger 3 3,264 11-10-2012, 10:53 AM
Last Post: seminar details
  A Quick Introduction to Voice over Internet Protocol (VoIP) computer girl 0 1,332 09-06-2012, 05:50 PM
Last Post: computer girl
  Internet Protocol Version 6 nit_cal 3 2,252 14-03-2012, 12:09 PM
Last Post: seminar paper
  Voice Over Internet Protocol computer science crazy 3 4,072 14-03-2012, 09:43 AM
Last Post: seminar paper
  Software Requirements Specification For DSP a Social Networking Site seminar surveyer 1 5,244 13-03-2012, 11:46 AM
Last Post: seminar paper
  Analog-Digital Hybrid Modulation for Improved Efficiency over Broadband Wireless Syst electronics seminars 8 5,293 13-03-2012, 10:23 AM
Last Post: seminar paper

Forum Jump: