sip_introduction.sgml

用来作为linux中SIP SERVER,完成VOIP网络电话中服务器的功能

<!-- $Id: sip_introduction.sgml,v 1.5 2004/08/24 08:45:13 janakj Exp $ -->
<!DOCTYPE Book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [

<!-- Include general SER documentation entities -->
<!ENTITY % serentities SYSTEM "../ser_entities.sgml">
%serentities;

]>

<book>
    <bookinfo>
	<title>&sip; Introduction</title>
	<authorgroup>
	    <author>
		<firstname>Jan</firstname>
		<surname>Janak</surname>
		<email>[e-mail]</email>
	    </author>
	</authorgroup>
	<copyright>
	    <year>2003</year>
	    <holder>&fhg;</holder>
	</copyright>
	<abstract>
	    <para>
		A brief overview of &sip; describing all important aspects of the Session Initiation
		Protocol.
	    </para>
	</abstract>
    </bookinfo>
    <toc></toc>

    <chapter>
	<title>&sip; Introduction</title>
	<section id="sec-purpose-of-sip">
	    <title>Purpose of &sip;</title>
	    <simpara>
		&sip; stands for Session Initiation Protocol. It is an application-layer control
		protocol which has been developed and designed within the &ietf;. The protocol has
		been designed with easy implementation, good scalability, and flexibility in mind.
	    </simpara>
	    <simpara>
		The specification is available in form of several <abbrev>RFCs</abbrev>, the most
		important one is &rfc3261; which contains the core protocol specification. The
		protocol is used for creating, modifying, and terminating sessions with one or more
		participants. By sessions we understand a set of senders and receivers that
		communicate and the state kept in those senders and receivers during the
		communication. Examples of a session can include Internet telephone calls,
		distribution of multimedia, multimedia conferences, distributed computer games, etc.
	    </simpara>
	    <simpara>
		&sip; is not the only protocol that the communicating devices will need. It is not
		meant to be a general purpose protocol. Purpose of &sip; is just to make the
		communication possible, the communication itself must be achieved by another means
		(and possibly another protocol). Two protocols that are most often used along with
		&sip; are &rtp; and &sdp;. &rtp; protocol is used to carry the real-time multimedia
		data (including audio, video, and text), the protocol makes it possible to encode
		and split the data into packets and transport such packets over the
		Internet. Another important protocol is &sdp;, which is used to describe and encode
		capabilities of session participants. Such a description is then used to negotiate
		the characteristics of the session so that all the devices can participate (that
		includes, for example, negotiation of codecs used to encode media so all the
		participants will be able to decode it, negotiation of transport protocol used and
		so on).
	    </simpara>
	    <simpara>
		&sip; has been designed in conformance with the Internet model. It is an end-to-end
		oriented signaling protocol which means, that all the logic is stored in end
		devices (except routing of &sip; messages). State is also stored in end-devices
		only, there is no single point of failure and networks designed this way scale
		well. The price that we have to pay for the distributiveness and scalability is
		higher message overhead, caused by the messages being sent end-to-end.
	    </simpara>
	    <simpara>
		It is worth of mentioning that the end-to-end concept of &sip; is a significant
		divergence from regular &pstn; (Public Switched Telephone Network) where all the
		state and logic is stored in the network and end devices (telephones) are very
		primitive. Aim of &sip; is to provide the same functionality that the traditional
		&pstn;s have, but the end-to-end design makes &sip; networks much more powerful and
		open to the implementation of new services that can be hardly implemented in the
		traditional &pstn;s.
	    </simpara>
	    <simpara>
		&sip; is based on &http; protocol. The &http; protocol inherited format of message
		headers from &rfc822;. &http; is probably the most successful and widely used
		protocol in the Internet. It tries to combine the best of the both. In fact, &http;
		can be classified as a signaling protocol too, because user agents use the protocol
		to tell a &http; server in which documents they are interested in. &sip; is used to
		carry the description of session parameters, the description is encoded into a
		document using &sdp;. Both protocols (&http; and &sip;) have inherited encoding of
		message headers from &rfc822;. The encoding has proven to be robust and flexible
		over the years.
	    </simpara>
	</section>
	<section id="sec-sip-uri">
	    <title>&sip; &uri;</title>
	    <simpara>
		&sip; entities are identified using &sip; &uri; (Uniform Resource Identifier). A
		&sip; &uri; has form of sip:username@domain, for instance,
		sip:[e-mail]. As we can see, &sip; &uri; consists of username part and
		domain name part delimited by @ (at) character. &sip; &uri;s are similar to
		e-mail addresses, it is, for instance, possible to use the same &uri; for e-mail
		and &sip; communication, such &uri;s are easy to remember.
	    </simpara>
	</section>
	<section id="sec-sip-network-elements">
	    <title>&sip; Network Elements</title>
	    <simpara>
		Although in the simplest configuration it is possible to use just two user agents
		that send &sip; messages directly to each other, a typical &sip; network will
		contain more than one type of &sip; elements. Basic &sip; elements are user agents,
		proxies, registrars, and redirect servers. We will briefly describe them in this
		section.
	    </simpara>
	    <simpara>
		Note that the elements, as presented in this section, are often only logical
		entities. It is often profitable to co-locate them together, for instance, to
		increase the speed of processing, but that depends on a particular implementation
		and configuration.
	    </simpara>
	    <section id="sec-user-agents">
		<title>User Agents</title>
		<simpara>
		    Internet end points that use &sip; to find each other and to negotiate a session
		    characteristics are called <emphasis>user agents</emphasis>. User agents
		    usually, but not necessarily, reside on a user's computer in form of an
		    application--this is currently the most widely used approach, but user agents
		    can be also cellular phones, &pstn; gateways, <acronym>PDAs</acronym>, automated
		    <acronym>IVR</acronym> systems and so on.
		</simpara>
		<simpara>
		    User agents are often referred to as <emphasis>User Agent Server</emphasis>
		    (&uas;) and <emphasis>User Agent Client</emphasis> (&uac;). &uas; and &uac; are
		    logical entities only, each user agent contains a &uac; and &uas;. &uac; is the
		    part of the user agent that sends requests and receives responses. &uas; is the
		    part of the user agent that receives requests and sends responses.
		</simpara>
		<simpara>
		    Because a user agent contains both &uac; and &uas;, we often say that a user
		    agent behaves like a &uac; or &uas;. For instance, caller's user agent behaves
		    like &uac; when it sends an INVITE requests and receives responses to the
		    request. Callee's user agent behaves like a &uas; when it receives the INVITE
		    and sends responses.
		</simpara>
		<simpara>
		    But this situation changes when the callee decides to send a BYE and terminate
		    the session. In this case the callee's user agent (sending BYE) behaves like
		    &uac; and the caller's user agent behaves like &uas;.
		</simpara>
		<figure id="fig-ua" float="0">
		    <title>&uac; and &uas;</title>		    
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/ua.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/ua.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing &uac; and &uas;</phrase>
			</textobject>
		    </mediaobject>
		</figure>
		<simpara>
		    <xref linkend="fig-ua"> shows three user agents and one stateful forking
		    proxy. Each user agent contains &uac; and &uas;. The part of the proxy that
		    receives the INVITE from the caller in fact acts as a &uas;. When forwarding the
		    request statefully the proxy creates two &uac;s, each of them is responsible for
		    one branch.
		</simpara>
		<simpara>
		    In our example callee B picked up and later when he wants to tear down the call
		    it sends a BYE. At this time the user agent that was previously &uas; becomes a
		    &uac; and vice versa.
		</simpara>
	    </section>
	    <section id="sec-proxy-servers">
		<title>Proxy Servers</title>
		<simpara>
		    In addition to that &sip; allows creation of an infrastructure of network hosts
		    called <emphasis>proxy servers</emphasis>. User agents can send messages to a
		    proxy server. Proxy servers are very important entities in the &sip;
		    infrastructure. They perform routing of a session invitations according to
		    invitee's current location, authentication, accounting and many other important
		    functions.
		</simpara>
		<simpara>
		    The most important task of a proxy server is to route session invitations
		    <quote>closer</quote> to callee. The session invitation will usually traverse a
		    set of proxies until it finds one which knows the actual location of the
		    callee. Such a proxy will forward the session invitation directly to the callee
		    and the callee will then accept or decline the session invitation.
		</simpara>
		<simpara>
		    There are two basic types of &sip; proxy servers--stateless and stateful.
		</simpara>

		<section id="sec-stateless-servers">
		    <title>Stateless Servers</title>
		    <simpara>
			Stateless server are simple message forwarders. They forward messages
			independently of each other. Although messages are usually arranged into
			transactions (see <xref linkend="sec-sip-transactions">), stateless proxies
			do not take care of transactions.
		    </simpara>
		    <simpara>
			Stateless proxies are simple, but faster than stateful proxy servers. They
			can be used as simple load balancers, message translators and routers. One
			of drawbacks of stateless proxies is that they are unable to absorb
			retransmissions of messages and perform more advanced routing, for instance,
			forking or recursive traversal.
		    </simpara>
		</section>
		<section id="sec-stateful-servers">
		    <title>Stateful Servers</title>
		    <simpara>
			Stateful proxies are more complex. Upon reception of a request, stateful
			proxies create a state and keep the state until the transaction
			finishes. Some transactions, especially those created by INVITE, can last
			quite long (until callee picks up or declines the call). Because stateful
			proxies must maintain the state for the duration of the transactions, their
			performance is limited.
		    </simpara>
		    <simpara>
			The ability to associate &sip; messages into transactions gives stateful
			proxies some interesting features. Stateful proxies can perform forking,
			that means upon reception of a message two or more messages will be sent
			out.
		    </simpara>
		    <simpara>
			Stateful proxies can absorb retransmissions because they know, from the
			transaction state, if they have already received the same message (stateless
			proxies cannot do the check because they keep no state).
		    </simpara>
		    <simpara>
			Stateful proxies can perform more complicated methods of finding a user. It
			is, for instance, possible to try to reach user's office phone and when he
			doesn't pick up then the call is redirected to his cell phone. Stateless
			proxies can't do this because they have no way of knowing how the
			transaction targeted to the office phone finished.
		    </simpara>
		    <simpara>
			Most &sip; proxies today are stateful because their configuration is usually
			very complex. They often perform accounting, forking, some sort of &nat;
			traversal aid and all those features require a stateful proxy.
		    </simpara>
		</section>
		<section id="sec-proxy-server-usage">
		    <title>Proxy Server Usage</title>
		    <simpara>
			A typical configuration is that each centrally administered entity (a
			company, for instance) has it's own &sip; proxy server which is used by all
			user agents in the entity. Let's suppose that there are two companies A and
			B and each of them has it's own proxy server. <xref linkend="fig-companies">
			shows how a session invitation from employee Joe in company A will reach
			employee Bob in company B.
		    </simpara>
		    <figure id="fig-companies" float="0">
			<title>Session Invitation</title>
			<mediaobject>
			    <imageobject>
				<imagedata align="center" scale="40" fileref="figures/companies.eps" format="EPS">
			    </imageobject>
			    <imageobject>