sip_introduction.sgml

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

		    code, and reason phrase.
		</simpara>
		<simpara>
		    The <emphasis>reply code</emphasis> is an integer number from 100 to 699 and
		    indicates type of the response. There are 6 classes of responses:
		</simpara>
		<itemizedlist>
		    <listitem>
			<simpara>
			    <emphasis>1xx</emphasis> are <emphasis>provisional</emphasis>
			    responses. A provisional response is response that tells to its
			    recipient that the associated request was received but result of the
			    processing is not known yet. Provisional responses are sent only when
			    the processing doesn't finish immediately. The sender must stop
			    retransmitting the request upon reception of a provisional response.
			</simpara>
			<simpara>
			    Typically proxy servers send responses with code 100 when they start
			    processing an INVITE and user agents send responses with code 180
			    (Ringing) which means that the callee's phone is ringing.
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>2xx</emphasis> responses are <emphasis>positive
			    final</emphasis> responses. A final response is the ultimate response
			    that the originator of the request will ever receive. Therefore final
			    responses express result of the processing of the associated
			    request. Final responses also terminate transactions. Responses with
			    code from 200 to 299 are positive responses that means that the request
			    was processed successfully and accepted. For instance a 200 OK response
			    is sent when a user accepts invitation to a session (INVITE request).
			</simpara>
			<simpara>
			    A &uac; may receive several 200 messages to a single INVITE
			    request. This is because a forking proxy (described later) can fork the
			    request so it will reach several &uas; and each of them will accept the
			    invitation. In this case each response is distinguished by the tag
			    parameter in To header field. Each response represents a distinct dialog
			    with unambiguous dialog identifier.
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>3xx</emphasis> responses are used to redirect a caller. A
			    redirection response gives information about the user's new location or
			    an alternative service that the caller might use to satisfy the
			    call. Redirection responses are usually sent by proxy servers. When a
			    proxy receives a request and doesn't want or can't process it for any
			    reason, it will send a redirection response to the caller and put
			    another location into the response which the caller might want to
			    try. It can be the location of another proxy or the current location of
			    the callee (from the location database created by a registrar). The
			    caller is then supposed to re-send the request to the new location. 3xx
			    responses are final.
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>4xx</emphasis> are <emphasis>negative final</emphasis>
			    responses. a 4xx response means that the problem is on the sender's
			    side. The request couldn't be processed because it contains bad syntax
			    or cannot be fulfilled at that server.
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>5xx</emphasis> means that the problem is on server's side. The
			    request is apparently valid but the server failed to fulfill it. Clients
			    should usually retry the request later.
			</simpara>
		    </listitem>
		    <listitem>
			<simpara>
			    <emphasis>6xx</emphasis> reply code means that the request cannot be
			    fulfilled at any server. This response is usually sent by a server that
			    has definitive information about a particular user. User agents usually
			    send a 603 Decline response when the user doesn't want to participate in
			    the session.
			</simpara>
		    </listitem>
		</itemizedlist>
		<simpara>
		    In addition to the response class the first line also contains <emphasis>reason
			phrase</emphasis>. The code number is intended to be processed by
		    machines. It is not very human-friendly but it is very easy to parse and
		    understand by machines. The reason phrase usually contains a human-readable
		    message describing the result of the processing. A user agent should render
		    the reason phrase to the user.
		</simpara>
		<simpara>
		    The request to which a particular response belongs is identified using the CSeq
		    header field. In addition to the sequence number this header field also contains
		    method of corresponding request. In our example it was REGISTER request.
		</simpara>
	    </section>
	</section> 
	<section id="sec-sip-transactions">
	    <title>&sip; Transactions</title>
	    <simpara>
		Although we said that &sip; messages are sent independently over the network, they
		are usually arranged into <emphasis>transactions</emphasis> by user agents and
		certain types of proxy servers. Therefore &sip; is said to be a
		<emphasis>transactional protocol</emphasis>.
	    </simpara>
	    <simpara>
		A transaction is a sequence of &sip; messages exchanged between &sip; network
		elements. A transaction consists of one request and all responses to that
		request. That includes zero or more provisional responses and one or more final
		responses (remember that an INVITE might be answered by more than one final response
		when a proxy server forks the request).
	    </simpara>
	    <simpara>
		If a transaction was initiated by an INVITE request then the same transaction also
		includes ACK, but only if the final response was not a 2xx response. If the final
		response was a 2xx response then the ACK is not considered part of the transaction.
	    </simpara>
	    <simpara>
		As we can see this is quite asymmetric behavior--ACK is part of transactions with a
		negative final response but is not part of transactions with positive final
		responses. The reason for this separation is the importance of delivery of all 200
		OK messages. Not only that they establish a session, but also 200 OK can be
		generated by multiple entities when a proxy server forks the request and all of them
		must be delivered to the calling user agent. Therefore user agents take
		responsibility in this case and retransmit 200 OK responses until they receive an
		ACK. Also note that only responses to INVITE are retransmitted !
	    </simpara>
	    <simpara>
		&sip; entities that have notion of transactions are called
		<emphasis>stateful</emphasis>. Such entities usually create a state associated with
		a transaction that is kept in the memory for the duration of the transaction. When a
		request or response comes, a stateful entity tries to associate the request (or
		response) to existing transactions. To be able to do it it must extract a unique
		transaction identifier from the message and compare it to identifiers of all
		existing transactions. If such a transaction exists then it's state gets updated
		from the message.
	    </simpara>
	    <simpara>
		In the previous &sip; &rfc2543; the transaction identifier was calculated as hash of
		all important message header fields (that included To, From, Request-URI and
		CSeq). This proved to be very slow and complex, during interoperability tests such
		transaction identifiers used to be a common source of problems.
	    </simpara>
	    <simpara>
		In the new &rfc3261; the way of calculating transaction identifiers was completely
		changed. Instead of complicated hashing of important header fields a &sip; message now
		includes the identifier directly. Branch parameter of Via header fields contains directly
		the transaction identifier. This is significant simplification, but there still exist old
		implementations that don't support the new way of calculating of transaction identifier so
		even new implementations have to support the old way. They must be backwards compatible.
	    </simpara>
	    <simpara>
		<xref linkend="fig-transactions"> shows what messages belong to what transactions
		during a conversation of two user agents.
	    </simpara>
	    <figure id="fig-transactions" float="0">
		<title>&sip; Transactions</title>
		<mediaobject>
		    <imageobject>
			<imagedata align="center" scale="40" fileref="figures/transaction.eps" format="EPS">
		    </imageobject>
		    <imageobject>
			<imagedata align="center" fileref="figures/transaction.png" format="PNG">
		    </imageobject>
		    <textobject>
			<phrase>Message flow showing messages belonging to the same transaction.</phrase>
		    </textobject>
		</mediaobject>
	    </figure>
	</section>
	<section id="sec-sip-dialogs">
	    <title>&sip; Dialogs</title>
	    <simpara>
		We have shown what transactions are, that one transaction includes INVITE and it's
		responses and another transaction includes BYE and it responses when a session is
		being torn down. But we feel that those two transactions should be somehow
		related--both of them belong to the same <emphasis>dialog</emphasis>. A dialog
		represents a peer-to-peer &sip; relationship between two user agents. A dialog
		persists for some time and it is very important concept for user agents. Dialogs
		facilitate proper sequencing and routing of messages between &sip; endpoints.
	    </simpara>
	    <simpara>
		Dialogs are identified using Call-ID, From tag, and To tag. Messages that have these
		three identifiers same belong to the same dialog. We have shown that CSeq header
		field is used to order messages, in fact it is used to order messages within a
		dialog. The number must be monotonically increased for each message sent within a
		dialog otherwise the peer will handle it as out of order request or
		retransmission. In fact, the CSeq number identifies a transaction within a dialog
		because we have said that requests and associated responses are called
		transaction. This means that only one transaction in each direction can be active
		within a dialog. One could also say that a <emphasis>dialog is a sequence of
		transactions</emphasis>. <xref linkend="fig-dialog"> extends <xref
		linkend="fig-transactions"> to show which messages belong to the same dialog.
	    </simpara>
	    <figure id="fig-dialog" float="0">
		<title>&sip; Dialog</title>
		<mediaobject>
		    <imageobject>
			<imagedata align="center" scale="40" fileref="figures/dialog.eps" format="EPS">
		    </imageobject>
		    <imageobject>
			<imagedata align="center" fileref="figures/dialog.png" format="PNG">
		    </imageobject>
		    <textobject>
			<phrase>Message flow showing transactions belonging to the same dialog.</phrase>
		    </textobject>
		</mediaobject>
	    </figure>
	    <simpara>
		Some messages establish a dialog and some do not. This allows to explicitly express
		the relationship of messages and also to send messages that are not related to other
		messages outside a dialog. That is easier to implement because user agent don't have
		to keep the dialog state.
	    </simpara>
	    <simpara>
		For instance, INVITE message establishes a dialog, because it will be later followed
		by BYE request which will tear down the session established by the INVITE. This BYE
		is sent within the dialog established by the INVITE.
	    </simpara>
	    <simpara>
		But if a user agent sends a MESSAGE request, such a request doesn't establish any
		dialog. Any subsequent messages (even MESSAGE) will be sent independently of the
		previous one.
	    </simpara>
	    <section id="sec-dialogs-facilitate-routing">
		<title>Dialogs Facilitate Routing</title>
		<simpara>
		    We have said that dialogs are also used to route the messages between user
		    agents, let's describe this a little bit.
		</simpara>
		<simpara>
		    Let's suppose that user sip:[e-mail] wants to talk to user sip:[e-mail]. He
		    knows &sip; address of the callee (sip:[e-mail]) but this address doesn't say
		    anything about current location of the user--i.e. the caller doesn't know to
		    which host to send the request. Therefore the INVITE request will be sent to a
		    proxy server.
		</simpara>
		<simpara>
		    The request will be sent from proxy to proxy until it reaches one that knows
		    current location of the callee. This process is called routing. Once the request
		    reaches the callee, the callee's user agent will create a response that will be
		    sent back to the caller. Callee's user agent will also put Contact header field
		    into the response which will contain the current location of the user. The
		    original request also contained Contact header field which means that both user
		    agents know the current location of the peer.
		</simpara>
		<simpara>
		    Because the user agents know location of each other, it is not necessary to send
		    further requests to any proxy--they can be sent directly from user agent to user
		    agent. That's exactly how dialogs facilitate routing.
		</simpara>
		<simpara>
		    Further messages within a dialog are sent directly from user agent to user
		    agent. This is a significant performance improvement because proxies do not see
		    all the messages within a dialog, they are used to route just the first request
		    that establishes the dialog. The direct messages are also delivered with much
		    smaller latency because a typical proxy usually implements complex routing
		    logic. <xref linkend="fig-trapezoid"> contains an example of a message
		    within a dialog (BYE) that bypasses the proxies.
		</simpara>
		<figure id="fig-trapezoid" float="0">
		    <title>&sip; Trapezoid</title>
		    <mediaobject>
			<imageobject>