sip_introduction.sgml

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

				<imagedata align="center" fileref="figures/companies.png" format="PNG">
			    </imageobject>
			    <textobject>
				<phrase>Picture showing a session invitation message flow</phrase>
			    </textobject>
			</mediaobject> 
		    </figure>
		    <simpara>
			User Joe uses address sip:[e-mail] to call Bob. Joe's user agent doesn't
			know how to route the invitation itself but it is configured to send all
			outbound traffic to the company &sip; proxy server proxy.a.com. The proxy
			server figures out that user sip:[e-mail] is in a different company so it
			will look up B's &sip; proxy server and send the invitation there. B's proxy
			server can be either pre-configured at proxy.a.com or the proxy will use
			<acronym>DNS SRV</acronym> records to find B's proxy server. The invitation
			reaches proxy.bo.com. The proxy knows that Bob is currently sitting in his
			office and is reachable through phone on his desk, which has &ip; address
			1.2.3.4, so the proxy will send the invitation there.
		    </simpara>
		</section>
	    </section>
	    <section id="sec-registrar">
		<title>Registrar</title>
		<simpara>
		    We mentioned that the &sip; proxy at proxy.b.com knows current Bob's location
		    but haven't mentioned yet how a proxy can learn current location of a
		    user. Bob's user agent (&sip; phone) must register with a
		    <emphasis>registrar</emphasis>. The registrar is a special &sip; entity that
		    receives registrations from users, extracts information about their current
		    location (&ip; address, port and username in this case) and stores the
		    information into location database. Purpose of the location database is to map
		    sip:[e-mail] to something like sip:bob@1.2.3.4:5060. The location database is
		    then used by B's proxy server. When the proxy receives an invitation for
		    sip:[e-mail] it will search the location database. It finds
		    sip:bob@1.2.3.4:5060 and will send the invitation there. A registrar is very
		    often a logical entity only. Because of their tight coupling with proxies
		    registrars, are usually co-located with proxy servers.
		</simpara>
		<simpara>
		    <xref linkend="fig-registrar"> shows a typical &sip; registration. A REGISTER
		    message containing Address of Record sip:[e-mail] and contact address
		    sip:jan@1.2.3.4:5060 where 1.2.3.4 is &ip; address of the phone, is sent to the
		    registrar. The registrar extracts this information and stores it into the
		    location database. If everything went well then the registrar sends a 200 OK
		    response to the phone and the process of registration is finished.
		</simpara>
		<figure id="fig-registrar" float="0">
		    <title>Registrar Overview</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/registrar.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/registrar.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing a typical registrar</phrase>
			</textobject>
		    </mediaobject> 
		</figure>
		<simpara>
		    Each registration has a limited lifespan. Expires header field or expires
		    parameter of Contact header field determines for how long is the registration
		    valid. The user agent must refresh the registration within the lifespan
		    otherwise it will expire and the user will become unavailable.
		</simpara>
	    </section>
	    <section id="sec-redirect-server">
		<title>Redirect Server</title>
		<simpara>
		    The entity that receives a request and sends back a reply containing a list of the
		    current location of a particular user is called <emphasis>redirect server</emphasis>. A
		    redirect server receives requests and looks up the intended recipient of the request in
		    the location database created by a registrar. It then creates a list of current
		    locations of the user and sends it to the request originator in a response within 3xx
		    class.
		</simpara>
		<simpara>
		    The originator of the request then extracts the list of destinations and sends
		    another request directly to them. <xref linkend="fig-redirect"> shows a typical
		    redirection.
		</simpara>
		<figure id="fig-redirect" float="0">
		    <title>&sip; Redirection</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/redirect.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/redirect.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing a redirection</phrase>
			</textobject>
		    </mediaobject> 
		</figure>
	    </section>
	</section>
	<section id="sec-sip-messages">
	    <title>&sip; Messages</title>
	    <simpara>
		Communication using &sip; (often called signaling) comprises of series of
		<emphasis>messages</emphasis>. Messages can be transported independently by the
		network. Usually they are transported in a separate &udp; datagram each. Each
		message consist of <quote>first line</quote>, message header, and message body. The
		first line identifies type of the message. There are two types of
		messages--<emphasis>requests</emphasis> and <emphasis>responses</emphasis>.
		Requests are usually used to initiate some action or inform recipient of the request
		of something. Replies are used to confirm that a request was received and processed
		and contain the status of the processing.
	    </simpara>
	    <simpara>
		A typical &sip; request looks like this:
	    </simpara>
	<programlisting format="linespecific">
INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP 195.37.77.100:5040;rport
Max-Forwards: 10
From: "jiri" &lt;sip:[e-mail]&gt;;tag=76ff7a07-c091-4192-84a0-d56e91fe104f
To: &lt;sip:[e-mail]&gt;
Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.20.128.35
CSeq: 2 INVITE
Contact: &lt;sip:213.20.128.35:9315&gt;
User-Agent: Windows RTC/1.0
Proxy-Authorization: Digest username="jiri", realm="iptel.org", 
  algorithm="MD5", uri="sip:[e-mail]", 
  nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c", 
  response="53fe98db10e1074
b03b3e06438bda70f"
Content-Type: application/sdp
Content-Length: 451

v=0
o=jku2 0 0 IN IP4 213.20.128.35
s=session
c=IN IP4 213.20.128.35
b=CT:1000
t=0 0
m=audio 54742 RTP/AVP 97 111 112 6 0 8 4 5 3 101
a=rtpmap:97 red/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:6 DVI4/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap: 3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
</programlisting>
	    <simpara>
		The first line tells us that this is INVITE message which is used to establish a
		session. The &uri; on the first line--sip:[e-mail] is called <emphasis>Request
		&uri;</emphasis> and contains &uri; of the next hop of the message. In this case it
		will be host iptel.org.
	    </simpara>
	    <simpara>
		A &sip; request can contain one or more Via header fields which are used to record
		path of the request. They are later used to route &sip; responses exactly the same
		way. The INVITE message contains just one Via header field which was created by the
		user agent that sent the request. From the Via field we can tell that the user agent
		is running on host 195.37.77.100 and port 5060.
	    </simpara>
	    <simpara>
		From and To header fields identify initiator (caller) and recipient (callee) of the
		invitation (just like in &smtp; where they identify sender and recipient of a
		message). From header field contains a tag parameter which serves as a dialog
		identifier and will be described in <xref linkend="sec-sip-dialogs">.
	    </simpara>
	    <simpara>
		Call-ID header field is a dialog identifier and it's purpose is to identify messages
		belonging to the same call. Such messages have the same Call-ID identifier. CSeq is
		used to maintain order of requests. Because requests can be sent over an unreliable
		transport that can re-order messages, a sequence number must be present in the
		messages so that recipient can identify retransmissions and out of order requests.
	    </simpara>
	    <simpara>
		Contact header field contains &ip; address and port on which the sender is awaiting
		further requests sent by callee. Other header fields are not important and will be
		not described here.
	    </simpara>
	    <simpara>
		Message header is delimited from message body by an empty line. Message body of the INVITE
		request contains a description of the media type accepted by the sender and encoded in
		&sdp;.
	    </simpara>
	    <section id="sec-sip-requests">
		<title>&sip; Requests</title>
		<simpara>
		    We have described how an INVITE request looks like and said that the request is
		    used to invite a callee to a session. Other important requests are:
		</simpara>
		<itemizedlist>
		    <listitem>
			<simpara>
			    <emphasis>ACK</emphasis>--This message acknowledges receipt of a final
			    response to INVITE. Establishing of a session utilizes 3-way
			    hand-shaking due to asymmetric nature of the invitation. It may take a
			    while before the callee accepts or declines the call so the callee's
			    user agent periodically retransmits a positive final response until it
			    receives an ACK (which indicates that the caller is still there and
			    ready to communicate).
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>BYE</emphasis>--Bye messages are used to tear down multimedia
			    sessions. A party wishing to tear down a session sends a BYE to the
			    other party.
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>CANCEL</emphasis>--Cancel is used to cancel not yet fully
			    established session. It is used when the callee hasn't replied with a
			    final response yet but the caller wants to abort the call (typically
			    when a callee doesn't respond for some time).
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>REGISTER</emphasis>--Purpose of REGISTER request is to let
			    registrar know of current user's location. Information about current
			    &ip; address and port on which a user can be reached is carried in
			    REGISTER messages. Registrar extracts this information and puts it into
			    a location database. The database can be later used by &sip; proxy
			    servers to route calls to the user. Registrations are time-limited and
			    need to be periodically refreshed.
			</simpara>
		    </listitem>
		</itemizedlist>
		<simpara>
		    The listed requests usually have no message body because it is not needed in
		    most situations (but can have one). In addition to that many other request types
		    have been defined but their description is out of the scope of this document.
		</simpara>
	    </section>
	    <section id="sec-sip-responses">
		<title>&sip; Responses</title>
		<simpara>
		    When a user agent or proxy server receives a request it send a reply. Each
		    request must be replied except ACK requests which trigger no replies.
		</simpara>
		<simpara>
		    A typical reply looks like this:
		</simpara>
		<programlisting format="linespecific">
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68
From: sip:[e-mail]
To: sip:[e-mail];tag=794fe65c16edfdf45da4fc39a5d2867c.b713
Call-ID: 2443936363@192.168.1.30
CSeq: 63629 REGISTER
Contact: &lt;sip:sip2@66.87.48.68:5060;transport=udp&gt;;q=0.00;expires=120
Server: Sip EXpress router (0.8.11pre21xrc (i386/linux))
Content-Length: 0
Warning: 392 195.37.77.101:5060 "Noisy feedback tells:  
    pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org 
    out_uri=sip:iptel.org via_cnt==1"
</programlisting>
		<simpara>
		    As we can see, responses are very similar to the requests, except for the first
		    line. The first line of response contains protocol version (SIP/2.0), reply