Session Initiation Protocol (SIP) is quickly gaining popularly with application service providers (ASPs), communication service providers(CSPs), and network service providers (NSPs) focused on offering their customers innovative, new IP - based services . Adopted in 1999 by the Internet Engineering Task Force (IETF) , SIP provides for the seamless transmission of voice, fax ,and data across IP and traditional telephone networks. The IETF defines SIP as “a text- based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality.” SIP is used to establish peer-to-peer media sessions on an IP network including Internet telephony, conferencing ,instant messaging, and unified messaging. SIP has become a standard IETF protocol for signaling in third-generation mobile networking because it is able to initiate, modify “terminal independent.” This seminar report deals with basic overview of SIP: Session Initiation Protocol. SIP – A protocol that allows voice, data, fax, video, instant messaging and even online gaming to be integrated with web-based applications. The session initiation protocol (SIP) is emerging as the favored standard for setting up, modifying and terminating telephone calls over the internet. Its main things on the fly-in the hands of the user.
1.1 Definition
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. A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
1.2 History
SIP has its origins in late 1996 as a component of the “Mbones” set of utilities and protocols. The Mbone or multicast backbone was an experimental multicast network overplayed on top of the public internet. It was used for distribution of multimedia content, including talks and seminars, broadcasts of space shuttle launches and IETF meetings. One of its essential component was a mechanism for inviting users to listen an ongoing or future multimedia session on the internet. Basically – a session ignition protocol. Thus SIP was born.
As an Mbone tool, SIP was designed with certain assumptions in mind.
First was scalability ► Since users could reside anyware on the internet, the protocol needed to work wide-area from day one. User could be invited to lots of sessions, so the protocol needed to scale in both directions.
A second assumption was component reuse ► Rather than inventing new protocol tools those already developed within the IETF would be used. That includes things like MIME, URLS and SDP. This resulted in a protocol that integrated well with other IP applications(such as web and e-mail).
Despite its historical strengths SIP saw relatively slow progress thought 1999. That’s about when interest in internet telephony began to take off. People began to see SIP as a technology that would also work for VoIP, not just Mbone sessions. The result was an intensified effort towards completing the specification in late 1998, and completion by the end of the year. It received official approval as RFC (Request for Comments, the official term for an IETF standard) in February and issuance of an RFC number, 2543, in March.
Form there, industry acceptance of SIP grew exponentially. Its scalability, extensibility, and most important flexibility appealed to service providers and vendors who had needs that a vertically integrated protocol, such as H.323, could not address. Among services MIC ( particularly MIC’s Henry Sinnreich, regarded as the “Pope” of SIP ) led the evangelical charge. Throughout 1999 and 2000, it saw adoption by most major vendors, and announcements of networks by service providers. Interoperability bake offs were held thought 1999, attendance doubling at each successive event. Tremendous success was achieved in interoperability among vendors. Other standard bodies began to look at SIP as well, including ITU and ETSI, TIPHON, IMTC, soft switch consortium, and JAIN. Looking forward, 2000 will be a year in which real SIP networks are deployed, SIP vendors step forward to announce real products, and applications and services began to appear.
An Internet Engineering Task Force (IETF) standard, SIP is an open, internet genuine protocol for establishing and managing multi party, mixed media sessions over converged networks. SIP enables the creation and deployment of feature rich services that go far beyond simple VoIP calls.
2.1 BASIC FUNCTION
As the name implies the session initiation protocol is about initiation interactive communications sessions between users. SIP also handles termination and modifications of sessions as well.
à Locating the user – supports personals mobility
à Inviting the user for session
à Delivering the session description
à Terminate the session
2.2 DESCRIPTION
The session initiation protocol is an application layer control protocol that can establish, modify and terminate multimedia sessions or calls. This multimedia session include multimedia conferences, distance learning, internet telephony and similar applications. SIP can invite both persons and “robots”, such as a media storage service. SIP can invite both parties to both unicast and multicast sessions. The initiator does not necessarily have to be a member of the session to which it is inviting. Media and participants can be added to and existing session. SIP can be used to initiates session as well as invite members to session that have been advertised and established by other means. Session can be advertised using multicast protocol such as SAP, E-Mail, News group, web pages or directories (LDAP), among others.
SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and intelligent network telephony subscriber services. These facilities also enable person mobility.
2.3 Five basic steps to established and terminate session
SIP supports five facts of establishing and terminating multimedia communications:
User Location ► Determination of the end system to be used for communication;
User capabilities ► Determination of the media and media parameters to be used;
User Availability ► Determination of the willingness of the called parties to engage in communications;
Call Setup ► “Ringing”, establishment of call parameters of both called and calling parties;
Call Handling ► Including transfer and termination of calls.
SIP can also initiates multi-parties calls using a multipoint control unit (MCU) or fully meshed interconnection instead of multicast. Internet telephony gateways that connect public switched Telephone Networks (PSTN) parties also use SIP to setup calls between them.
A call consistent of all participates in a conferences invited by a common source. A SIP call is identified by a global unique call ID.Thus, if a user is , for example invited to the same multicast session by several people , each of these invitations will be a unique call . A point to point internet telephony conversation maps into a single SIP call. In a Multiparty Conferences Unit (MCU) based call-in conference, each participate uses a separate call to invite himself to the MCU.Invitation is a request sent to a user requesting participation in a session conferences is a multimedia session ,identified by a common session description.
SIP session can three different multiparty conferencing architecture:
Full mesh ► In a mesh participant builds a signaling with every other participant & sent an individual copy of the media stream to the others. This mechanism only scales to very small groups.
Mixers ► A mixers or bridge takes several media streams & replaces them to all participates. Typically audio is mixed, while video is either simply copied or combined into a single image .Participants either call into the mixer or are called by the mixer; both mechanisms are readily supported in SIP, without protocol addition.
N/W layer multicast ► Neither full mesh nor mixers scale to large conferences.
These are most efficiently supported by n/w layer multicast.
Most of SIP is about the initiation part, since this is really the most difficult aspect. “Initiating a session” requires determining where the user to be contacted is actually residing at a particular moment. a user might have a PC at work a PC at home and an IP desk phone in the lab. A call for that user might needed to ring all phones at once. Furthermore, the user might be mobile; one day at work, and the next day visiting a university .This dynamic location information needs to be taken into account in order to find the user.
Once the user to be called has been located, SIP can perform its second main function – delivering a description of the session that the user is being invited to. SIP itself does not know about the details of the session. What SIP does do is convey information about the protocol used to describe the session.
SIP does this through the use of multipurpose internet mail extensions (MIME), Widely used in web and e-mail services to describe content (HTML, audio, video, etc).The most common protocol used to describe sessions is the session description protocol (SDP), described in RFC2327.SIP can also be used to negotiate a common format for describing session, so that other things besides SDP can be used.
SIP is used to convey the response to the session initiation (accept, reject, etc.) If accepted, the session is now active .SIP can be used to modify the session as well. Doing so is easy – the originator simply re-initiate the session, sending the same message as the original, but with a new session description. For this reason, modification of session (Which includes things like adding and removing audio streams ,adding video, changing codes ,hold and mute) are easily supported with SIP , so long as the session description protocol can support them (SDP supports all of the above).
3.1 Basic Architecture
Four logical types of entities participate in SIP:
àUser Agents
àProxy server
àRedirect server
àRegistrars
3.1.1 User Agents
User agent is an application which contains both a user agent client and user agent server. A user agent client (UAC) is a client application that initiates the SIP request. A user agent server (UAS) is a server application that contacts the user when a SIP request is received. An application program may be capable of acting both as a client and a server. For example, a typical multimedia conferences control application would act as a user agent client to initiate calls or to invite others to conferences and as a user agent server to accept invitations. Internet telephone & conferencing software are example of user agent.
3.1.2 Proxy, proxy server
An intermediary program that acts as both a server and a client for the purpose of making request on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers .A proxy interprets, and if necessary, rewrites a requests message before forwarding it. Thus we, can say that Proxy Servers are application layer routers that forward SIP request & responses.
3.1.3 Redirect server
A redirect server is a server that accepts a SIP Requests & then return the location of another SIP user agent & server where the user might be found. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls.
3.1.4 Registrar
A registrar is a server that accepts REGISTER requests. A registrater is typically co-located with a proxy or redirect server and offer location services. A location services is used by a SIP redirect or proxy server to obtain information about a callee’s possible location(s). Location services are offered by location server. Location servers may be co-located with a SIP server.Registraters keep track of user within their assigned n/w domains. (E.g. All users with the identifiers x@macrosoft.com register with the registrar in the Microsoft .com domain).
In a typical SIP session, SIP message originates at a user agent traverse one or more SIP proxy servers & then reach one or more SIP user agents. However , SIP user agents can also , communicate directly , with each other .Indeed, it is common that only the first request exchange travels along a chain of proxies ,with all subsequent requests exchanged directly between the two user agents.
3.2 SIP OPERATION
Callers and callee are identified by SIP addresses. When making a SIP call, a caller locates the appropriate server and then sends a SIP request. The most common SIP operation is the invitation. Instead of directly reaching the intended callee’s SIP request may be redirected or may trigger a chain of new SIP requests by proxies.
3.2.1 SIP Addressing
The “objects” addressed by SIP are users at hosts, identified by a SIP URL .The SIP URL takes a form similar to a mail to or telnet URL i.e. user@host. The user part is a user name or a telephone number. The host part is either a domain name or a numeric network address. A user’s SIP address can be obtained out-of-band, can be learned via existing media agents, can be included in some mailer’s message headers, or can be recorded during previous invitation interaction. In many cases, a user’s SIP URL can be guessed from their email address. A SIP URL address can designate an individual (possibly located at one of several end systems), the first available person from a group of individuals or a whole group. The form of the address for example sip:sales@example.com is not sufficient in general to determine the intent of the caller. If a user or services choose to be reachable at an address that is guessable from the person’s name and organizational affiliation, the traditional method of ensuring privacy by having an unlisted “phone” number is compromised. However, unlike traditional telephony, SIP offers authentication and access control mechanisms and can avail itself of lower-layers security mechanisms so that client software can reject unauthorized or undesired call attempts.
3.2.2 Locating a SIP Server
When a client wishes to send a request, the client either sends it to a locally configured SIP proxy server, independent of the request-URL or sends it to the IP –address and port corresponding to the Request-URL
For the latter case the client must determine the protocol, port and IP address of a server to which to send the request. at each step unless stated otherwise, the client should try to contact a server at the port number listed in the Request-URL .If the Requests specifies a protocol (TCP or UDP ),the client tries UDP .If the attempt fails, or if the client doesn’t support UDP but supports TCP ,it then tries TCP.
A client should be able to interpret explicit network notification which indicates that a server is not reachable rather than relying solely on timeouts. If the client finds the server is not reachable at a particular address, it should behave as if had received instead of a full SIP URL for a callee, however. In that case implementations may be able to increase the like hood of reachable a SIP server for that domain by constructing a SIP URL from that email address by prefixing the host name with “SIP”. In the future, this mechanism is likely to become unnecessary as better DNS techniques, becomes widely available.
3.2.3 SIP Transaction
Once the host part has been resolved to a SIP server, the client sends one or more SIP requests to that server and receives one or more responses from the server. A request together with the responses triggered by that requests make up a SIP transaction. All responses to a request contain the same values in the call-ID, CSeq (command sequence no), to, and from fields. This allows responses to be matched with requests. The ACK request following an INVITE is not part of the transaction since it may traverse a different set of hosts.
If TCP is used, request and responses within a single SIP transaction are carried over the same TCP connection .Several SIP requests from the same client to the same server may use the same TCP connection or may use a new connection for each requests. If the client sent the requests via unicast UDP the responses is sent to the address contained in the next via header field of the responses. If the request is sent via multicast UDP, the response is directed to the same multicast address and destination port. For UDP reliability is achieved using retransmission.
The SIP message format and operation is independent of the transport protocol.
3.2.4 SIP Invitation
A successful SIP invitation of two requests, INVITE followed by ACK.The INVITE request asks the callee to join particular conferences or establish a two-party conversation that it has received that response by sending an ACK request. If the caller no longer wants to participate in the call, it sends a BYE request instead of an ACK.
The INVITE request typically contains a session description, for example written in SDP format that provides the called party with enough information to join the session. For multicast sessions, the session description enumerates the media types and formats that are allowed to be description to that session.
For a unicast session, the session description enumerates the media types and format that the either case if the callee wishes to accept the call it responds to the invitation by returning a similar description listing the media it wishes to use. For a multicast session, the callee should only return a session description if it is unable to receive the media indicated in the caller’s description or wants to receive data via unicast.
3.2.5 Locating a user
A collee may move between a numbers of different end systems over time. These locations can be dynamically registered with the SIP server. A location server may also use one or more other protocols such as finger (RFC 1288), rwhois (RFC 2167), LDAP (RFC 1777), multicast-based protocols for operating systems dependent mechanisms to actively determine the end system where a user might be reachable. A location server may return several locations because the user is logged in at several hosts simultaneously or because the location server has inaccurate information. The SIP server combines the results to yield a list of a zero or more locations.
The action on taken on receiving a list of location varies with the type of SIP server .a SIP redirect server returns the list to the client as context headers. A SIP proxy server can sequentially or in parallel try the address until the call is successful or the callee has declined the call.
If a proxy server forwards a SIP request, it must add itself to the beginning of the list of forwards in the headers. This ensures that replies can takes the same path back, ensuring correct operation avoiding request loops. On the response path each host must remove its entry from the list so that routing internal information Is hidden from the callee and outside networks.
A SIP invitation traverse more than one SIP proxy server .If one of these “forks” the request ,i.e. issues more than one request in response to receiving the invitation request it is possible that a client is reached independently by more than one copy of the invitation request . Each of these copies bears the same call-ID. The user agent must return the same status response return in the first response.Duplicsate requests are not an error.
3.2.6 Changing an Existing Session
In some circumstances it is desirable to change the parameters of an existing session. This is done by re-issuing the INVITE, using the same call-ID but a new or different body or header fields to convey the new information. This re INVITE must have a higher CSeq than any previous request from the client to the server.
For Example two parties may have been conversing and then want to add a third party, switching to multicast for efficiency .One f the participants invites the third party with the new multicast address and simultaneously sends an INVITE to the second party , with the new multicast session description but with the old call identifier.
3.2.7 Registration Services
The REGISTER request allows a client to let a proxy or redirect server know at which address it can be reached. A client may also use it to install call handling features at the server.
3.3 MODES OF OPERATION
SIP basically operation in two modes:
àProxy server mode
àRedirect Mode
3.3.3 proxy server mode
As shown in fig 1 the basic operation can be summarized in the following steps:
Step 1: The proxy server accepts the INVITE request
Step2: contacts the location services with all or parts of the address
Step 3: obtain a more precise location
Step 4: the proxy server then issues a SIP INVITE request to the address returned by the location services
Step 5: the user agent alerts the user
Step 6: Return a success indication to the proxy server
Step 7: the proxy server then return the success result to the original caller.
Step 8 & 9: the receipt of this message is confirming by the caller using an ACK request which is forwarded to the cal lee. An ACK can also be sent directly to the cal lee by passing the proxy .All requests and responses have the call ID.
3.3.4 REDIRECT MODE
As shown in the fig 2. The basic operation can be summarized in the following steps.
Step1: Accepts the INVITE request
Step2: contact the location services
Step 3: obtain a more precise location
Step4: instead of contacting the newly found address itself return the address to the caller
Step5: ACK request.
Step6: The caller issues a new request with the same call-id but a higher CSeq to the address returned by the first server.
Step 7: the call succeeds.
Step8: the caller and cal lee complete the handshake with an ACK.
4.1 Minimal State
A single conference session or call involves one or more SIP request response transactions proxy server do not have to keep state for a particular call, however they may maintain state for a single SIP transaction . For efficiency, a server may cache the results of location services requests.
4.2 Lower-Layer-Protocol Neutral
SIP makes minimal assumption about the underlying transport and network-layer protocols. The lower-layer can provides either a packet or a byte stream services with reliable or unreachable services. In an internet context SIP is able to utilize both UDP and TCP as transport protocols among others.UDP allows the application to more carefully control the timing of message and their retransmitting to perform parallel searches without requiring TCP connection state for each outstanding request and to use multicast. Routers can more readily snoop SIP UDP packets.TCP allows easier passage through existing firewalls.
When TCP is used, SIP can use one or more connections to attempts to contact a user or to modify parameters of an existing conference. Different SIP requests for the same SIP call may use different TCP connections or a single persistence connection, as appropriate.
However SIP may also be used directly with protocols such as ATM frame relay or X.25 .User agent implement both UDP and TCP transport. Proxy registrar and redirect servers must implement both UDP and TCP transport.
4.3 Text-Based
SIP is text-based using ISO 10646 in UTF-8 encoding throughout. This allows easy implementation in language such as java, Tcl and Perl, allows easy debugging and most importantly makes SIP flexible and extensible. As SIP is used for initiating multimedia conferences rather than delivering media data it is believed that the additional overhead of using a text-based protocol is not significant.
5.1 SIP URL
SIP URLs are used within SIP message to indicate the originator (FROM), current (Request-URL) and final recipient (To) of a SIP request , and to specify redirection addresses (Contact).A SIP URL can also be embedded in web pages or other hyperlinks to indicate that a particular user or service can be called via SIP. When used as a hyperlink, the SIP URL indicates the use of the INVITE method.
The SIP URL scheme is defined to allow setting SIP request-header fields and the SIP message-body. This corresponds to the use of mail to: URLs. It makes it possible, for example, to specify the subject, urgency or media types of calls initiated through a web page or as part of an email message. SIP URLs are case-insensitive, so that for example the two URLs sip:j.doe@example.com and SIP:j.doe@Example.com are equivalent, All URL parameters are included when comparing SIP URLs for equality. SIP header fields may contain non-SIP URLs. As an example, if a call from telephony is relayed to the internet via SIP, the SIP from header field might contain a phone URL.
5.2 SIP Message Overview
SIP is a text-based protocol. Senders must terminate lines with a CRLF, but receivers must also interpret CR and LF by themselves as line terminators. Except for the above different in character sets, much of the message syntax and header fields are identical to HTTP/1.1; however, that SIP is not an extension of HTTP.
A SIP message is either a request from a client from a client to a server, or a response from a server to a client.
SIP – Message = Request | Response
Both request and response message use the generic-message format for transferring entities (the body of the message). Both types of messages consist of a start-line, one or more header fields (also known as “headers”), an empty line (i.e., a line with nothing preceding the carriage-return line-feed (CRLF)) indicating the end of the header fields, and an optional message-body. To avoid confusion with similar-named header in HTTP, the headers describing the message body are known as “entity header”.
Generic-Message = Start-Line
* Message-Header
CRLF
[Message-Body]
Start-Line = Request-Line | Status-Line
Message-header = (general – header
| Request-header
| Response-header
| entity-header)
In the interest of robustness, any leading empty line(s) must be ignored. In other words, if the request or response message begins with one or more CRLF, CR, or LFs, these characters must be ignored, The Request message format is shown below:
Request = Request-Line
* (general-header
| Request-header
| entity-header)
CRLF [message-body]
5.3 SIP Message Body
Requests may contain message bodies unless otherwise noted. within this specification, the BYE request must not contain a message body. For ACK, INVITE and OPTIONS, the message body is always a session description.
5.3.1 Message Body Type
The internet media type of the message body must be given by the content-type header field. If the body has undergone any encoding header field, otherwise content-Encoding must be omitted. If applicable, the character set of the message body is indicating as a part of the content-type header-field value.
5.3.2 Message Body Length
The body length bytes should in byte be given by the content-length header field. When SIP is carried over UDP with authentication and a complex session description, it may be possible that the size of the request or responses is larger than the MTU. To address this problem, a more compact form of SIP is also defined by using abbreviation for the common header listed below:
| Short Field Name | Long Field Name |
| C | Content type |
| E | Content encoding |
| F | From |
| I | Call ID |
| M | Contact ( Moved) |
| L | Content length |
| S | Subject |
| T | To |
| V | Via |
Clients may mix short field names and long field names within the same request. Servers must accept both short and long field names for requests. Proxies may change header fields between their long and short forms, but this must not be done to fields following an authorization header.
6.1 Encryption
SIP requests and responses can contain sensitive information about the communication patterns and communication content of individuals. The SIP message body may also contain encryption keys for the session itself. SIP supports three complementary forms of encryption to protect privacy:
àEnd –to- End encryption of the SIP message body and certain sensitive header fields;
àHop-by-hop encryption to prevent eavesdropping that tracks who is calling whom;
àHop-by-hop encryption of via fields to hide the route a request has taken.
Not all of the SIP request or responses can be encrypted end-to-end because header fields such as to and via need to be visible to proxies so that the SIP request can be routed correctly.
Hop-by-hop encryption encrypts the entire SIP request or responses on the wire so that packet sniffers or other eavesdroppers cannot see who is calling whom. Hop-by-hop encryption can also encrypt requests and responses that whom have been end-to-end encrypted. However proxies can still see who is calling whom and this information is also deducible by performing a network traffic analysis, so this provides a vary limited but still worthwhile degree of protection .SIP via fields are used to route a responses back along the path taken by the request and to prevent infinite request loops .However the information given by them can also provide useful information to an attacker. End-to-End encryption relies on keys shared by the user agents involved in the request. Typically, the message is sent encrypted with the public key of the recipient, so that only that recipient can read the message.
A SIP request is end-to-end encrypted by splitting the message to be sent into a part to be encrypted and a short header that will remain in the clear. Some parts of the SIP message, namely the request line the responses line and certain header fields need to be possibly sensitive information that needs to be made available as plaintext include destination address and the forwarding of the call
6.2 Message Integrity and Acess Control : Authentication
Protective measure need to be taken to prevent an active attacker from modifying and replaying SIP requests and responses. The same cryptographic measure that are used to ensure the authenticity of the SIP message also serve to authenticate the originator of the message .SIP requests may be authenticated using the authorization header field to include a digital signature of certain header fields, the request method and version number and the payload, none of which are modified between client and called user agent .The authorization header field is used in requests to authenticate the request originator end-to-end to proxies and the called user agent, and in responses to authenticate the called user agent or praxes returning the failure codes .If required ,hop-by-hop authentication can be provided ,for example by the IPSec Authentication header.
6.3 Callee Privacy
User location and SIP –initiated calls can violate a callee’s privacy. An implementation should be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers.
7.1 SIP Services Provisioning
SIP services can be created by services providers, enterprise administered and IT departments, or even directly by the end users. By grouping up innovation to the public at large, all sorts of new services and features can be developed, creating entire new markets. The same thing is seen in the web space anyone with an idea and a few dollars can put together new content. In overcoming the highly centralized and carrier- controlled model of telephony and in putting tools for services creation in so many hands’ SIP has the potential to deliver what the PSTN intelligent Network only promised. Besides the traditional foe enabling ac whole new class of services that integrate multimedia with web,e-mail,instant messaging and “presence” (means is “are you currently online”).The value that the internet brings to internet telephony is the suite of existing applications that can be merged with voice and video communications. As an example at the end of a call a user can transfer the other party to a web page instead of another phone. This transfer would end the call and cause the other party’s web browser to jump to the new page.
7.2 HOW TO PROGRAM IT?
In programming, of course requires APIs.The first API that surfaced is the calls processing language (CPL).CPL is not actually an API, but rather an XML-based scripting language for describing call services. It is not a complete programming language .It has primitive for making decisions based on call properties, such as forwarding calls, rejecting call, redirecting calls and sending e-mail.CPL is engineered for end user services creation. A server can easily parse and validate a CPL services requirement of a CPL guarding against malicious behavior. The running time and resources requirement of a CPL.An interpreter for CPL is very lightweight allowing CPL services to execute very quickly. For these reasons, it is possible for an end user to write a CPL, uploaded it to the work and have it instantly verified and instantiated in a real time. At the opposite end of the the spectrum in SIP is CGI .many web designers are familiar with HTTP CGI; it’s an interface that allows people to generate dynamic web content using Perl, Tel, or any other programming language of choice .Since HTTP and SIP are so similar it was recognized that an almost identical interface could be used for SIP. The result is SIP CGI, which is roughly 90 % equivalent to HTTP CGI. Like HTTP CGI, SIP CGI passes message process. The process sends instructions back to the server through its standard output file descriptor. The benefit of SIP CGI is that it takes development of SIP services. The benefit of the SIP CGI is that it makes development of SIP services work much like the creation of dynamic web content. In fact , for SIP services that contain substantial web components ,development will closely mirror web-only services.\the importance of leveraging becomes available.CGI has substantially more flexibility than CPL but is much more risky to execute .Furthermore because of its usage of separate processes SIP CGI doesn’t scale as well as CPL.Somewhere in the middle are SIP Servlets.HTTP servelets are in wide use for developing dynamic web content. Servlets are very similar to the CGI concept. However instead of using a separate process massage are passed to a class that runs within a JVM (Java Virtual Machine) inside of the server .As a result, servlets are restricted to java but suffer less overhead than SIP CGI.Use of JVM for executing servlets means that the java “sandbox” concept can be applied to protect the server from the script. Like SIP CGI ,SIP servlets closely mirror the operation of HTTP servlets; they simple enhance the interface to support the wider array of functions a proxy can execute as compared to an HTTP origin server .Besides these new APIs traditional APIs can also be used to develop SIP services .
7.3 QUALITY Of SERVICE (QoS)
Perhaps the most vexing problem in voice-over-IP, in general has been the issue of quality .the delay in conversations that many VoIP users encounter is caused by the jitter and latency of packets delivery within the internet itself.curently the internet offers a single traditionally referred to as “best efforts” in other all packets are created equal. There is no difference to the internet whether a packet is e-mail, FTP, or the download of a web page. If the internet gets very busy packets or delayed unfortunanately the human ear is extremely sensitive to latency in the delivery of sound. The human ear can detect of 200 milliseconds or greater in voice conversations.
SIP itself does not get involved in reservation of network resources or admission control. This is because SIP messages may not even run over the same networks that the voice packets traverse. The complete independence of the provide SIP path and the voice path enables ASPs to provide voice services without providing network connectivity. This is an extremely important advantage of the SIP architechure.Given this SIP relies on other protocols and techniques in order to provide quality of service. Most user have dealt with QoS issues by either adding bandwidth to their networks or by applying complex and expensive framing techniques such as ATM to IP traffic. This may be sensible intra-enterprise VoIP configuration since the network can be administered directly. However when internet traffic must exit a domain or a particular carrier boundary, all bets are off, other methods must be used. To create QoS on the internet, you must create different classes of services for packets.
8.1 Application
Using the signaling capabilities of the session initiation protocol (SIP), a new generation of smart phones, conferencing units and even soft phones for PCs will bring new power to desktops and pump even more energy into the already accelerating market for voice on the LAN .According to a new study from The Phillips Group InfoTech titled “IP LAN” Telephony: Market Demand
à Taiwan’s state-owned telecom operator Chunghwa Telecom, of Taipei is poised to become the first regional carrier to deploy a new generation of internet services based on the telephone. Session initiation protocol (SIP) based services have been launched by operators in Europe, but Chunghwa will be the first to roll out commercially in pacific Asia,according to sources close to the company.
8.2 FUTURE DIRECTION
SIP itself will move through the IETF process from proposed standard RFC to the next stage, draft standard RFC. As proposed standard RFC, standards begin to get deployed and gain implementation experience. Invariably, problems and inconsistencies are found, and these are corrected as the draft RFC version is built.
Numerous extensions are also under development. Several of these fall under the umbrella of “SIP-T”, or “SIP for telephony” providing a way for traditional PSTN signaling message, such as ISUP, to be carried in SIP messages. This allows SIP to be used between gateways softswitches in a way that provides complete transparency while retaining its strength and services.
Another extension is aimed at connecting the caller to the right terminal for a given user. Called “caller preferences”and“callee capabilities:, the extension incorporates presence information into SIP message .A caller can request a call for joe@company.com to be routed to Joe’s mobile phone, or to a PC client that supports video.
Much work is also in progress on supporting infrastructure. This includes an SNMP Management information base(MIB) for management of SIP servers ,gateways and client, DHCP option codes for SIP to support auto configuration and QoS mechanisms that permit SIP session takes place only if sufficient bandwidth exists to support them.
CONCLUSION
SIP is now a days used for internet conferences, internet multimedia, internet telephony calls at distance learning with compatible session like voice, chat , traditional telephony networks, voice, fax, interactive games etc. SIP become a standard IETF protocol for signaling in third – generation mobile networking SIP runs on top of several different transport protocols.
BIBLIOGRPHY
1. www.cs.columbia.edu/sip - Session Initiation Protocol – Internet Centric Signaling
2. www.computertelephony.com-SIP: A Key Component for Telephony
3. www.cisco.com/univered/product/voice/sipsols/bgsipov.pdf
4. www.protocol.com/voip/sip_arch.htm
5. www.ietf.org/html.charter/enum-charter.htm
Book Reference
IP Telephony: The Integration of Robust VoIP Services
By Bill Dousakalis, published by Person Education Asia 2001
No comments:
Post a Comment
leave your opinion