sip_introduction.sgml

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

			    <imagedata align="center" scale="40" fileref="figures/trapezoid.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/trapezoid.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Message flow showing &sip; trapezoid.</phrase>
			</textobject>
		    </mediaobject>
		</figure>
	    </section>
	    <section id="sec-dialog-identifiers">
		<title>Dialog Identifiers</title>
		<simpara>
		    We have already shown that dialog identifiers consist of three parts, Call-Id,
		    From tag, and To tag, but it is not that clear why are dialog identifiers
		    created exactly this way and who contributes which part.
		</simpara>
		<simpara>
		    Call-ID is so called <emphasis>call identifier</emphasis>. It must be a unique
		    string that identifies a call. A call consists of one or more dialogs. Multiple
		    user agents may respond to a request when a proxy along the path forks the
		    request. Each user agent that sends a 2xx establishes a separate dialog with the
		    caller. All such dialogs are part of the same call and have the same Call-ID.
		</simpara>
		<simpara>
		    From tag is generated by the caller and it uniquely identifies the dialog in the
		    caller's user agent.
		</simpara>
		<simpara>
		    To tag is generated by a callee and it uniquely identifies, just like From tag,
		    the dialog in the callee's user agent.
		</simpara>
		<simpara>
		    This hierarchical dialog identifier is necessary because a single call
		    invitation can create several dialogs and caller must be able to distinguish
		    them.
		</simpara>
	    </section>
	</section>
	<section id="sec-typical-sip-scenarios">
	    <title>Typical &sip; Scenarios</title>
	    <simpara>
		This section gives a brief overview of typical &sip; scenarios that usually make up the
		&sip; traffic.
	    </simpara>
	    <section id="sec-registration">
		<title>Registration</title>
		<simpara>
		    Users must register themselves with a registrar to be reachable by other
		    users. A registration comprises a REGISTER message followed by a 200 OK sent by
		    registrar if the registration was successful. Registrations are usually
		    authorized so a 407 reply can appear if the user didn't provide valid
		    credentials. <xref linkend="fig-register"> shows an example of registration.
		</simpara>
		<figure id="fig-register" float="0">
		    <title>REGISTER Message Flow</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/register.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/register.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Message flow of a registration.</phrase>
			</textobject>
		    </mediaobject>
		</figure>
	    </section>
	    <section id="sec-session-invitation">
		<title>Session Invitation</title>
		<simpara>
		    A session invitation consists of one INVITE request which is usually sent to a
		    proxy. The proxy sends immediately a 100 Trying reply to stop retransmissions
		    and forwards the request further.
		</simpara>
		<simpara>
		    All provisional responses generated by callee are sent back to the caller. See
		    180 Ringing response in the call flow. The response is generated when callee's
		    phone starts ringing.
		</simpara>
		<figure id="fig-invite1" float="0">
		    <title>INVITE Message Flow</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/invite1.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/invite1.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing a session invitation.</phrase>
			</textobject>
		    </mediaobject>
		</figure>
		<simpara>
		    A 200 OK is generated once the callee picks up the phone and it is retransmitted
		    by the callee's user agent until it receives an ACK from the caller. The session
		    is established at this point.
		</simpara>
	    </section>
	    <section id="sec-session-termination">
		<title>Session Termination</title>
		<simpara>
		    Session termination is accomplished by sending a BYE request within dialog
		    established bye INVITE. BYE messages are sent directly from one user agent to
		    the other unless a proxy on the path of the INVITE request indicated that it
		    wishes to stay on the path by using record routing (see <xref
		    linkend="sec-record-routing">.
		</simpara>
		<simpara>
		    Party wishing to tear down a session sends a BYE request to the other party
		    involved in the session. The other party sends a 200 OK response to confirm the
		    BYE and the session is terminated. See <xref linkend="fig-bye">, left message
		    flow.
		</simpara>
	    </section>
	    <section id="sec-record-routing">
		<title>Record Routing</title>
		<simpara>
		    All requests sent within a dialog are by default sent directly from one user agent
		    to the other. Only requests outside a dialog traverse &sip; proxies. This approach
		    makes &sip; network more scalable because only a small number of &sip; messages hit
		    the proxies.
		</simpara>
		<simpara>
		    There are certain situations in which a &sip; proxy need to stay on the path of all
		    further messages. For instance, proxies controlling a &nat; box or proxies doing
		    accounting need to stay on the path of BYE requests.
		</simpara>
		<simpara>
		    Mechanism by which a proxy can inform user agents that it wishes to stay on the path
		    of all further messages is called <emphasis>record routing</emphasis>. Such a proxy
		    would insert Record-Route header field into &sip; messages which contain address of
		    the proxy. Messages sent within a dialog will then traverse all &sip; proxies that
		    put a Record-Route header field into the message.
		</simpara>
		<simpara>
		    The recipient of the request receives a set of Record-Route header fields in the
		    message. It must mirror all the Record-Route header fields into responses because
		    the originator of the request also needs to know the set of proxies.
		</simpara>
		<figure id="fig-bye" float="0">
		    <title>BYE Message Flow (With and without Record Routing)</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/bye.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/bye.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing BYE message flow with and without record routing.</phrase>
			</textobject>
		    </mediaobject>
		</figure>
		<simpara>
		    Left message flow of <xref linkend="fig-bye"> show how a BYE (request
		    within dialog established by INVITE) is sent directly to the other user agent
		    when there is no Record-Route header field in the message. Right message flow
		    show how the situation changes when the proxy puts a Record-Route header field
		    into the message.
		</simpara>
		<section>
		    <title>Strict versus Loose Routing</title>
		    <simpara>
			The way how record routing works has evolved. Record routing according to
			&rfc2643; rewrote the Request-URI. That means the Request-URI always
			contained &uri; of the next hop (which can be either next proxy server which
			inserted Record-Route header field or destination user agent). Because of
			that it was necessary to save the original Request-URI as the last Route
			header field. This approach is called <emphasis>strict routing</emphasis>.
		    </simpara>
		    <simpara>
			<emphasis>Loose routing</emphasis>, as specified in &rfc3261;, works in a
			little bit different way. The Request-URI is no more overwritten, it always
			contains &uri; of the destination user agent. If there are any Route header
			field in a message, than the message is sent to the &uri; from the topmost
			Route header field. This is significant change--Request-URI doesn't
			necessarily contain &uri to which the request will be sent. In fact, loose
			routing is very similar to IP source routing.
		    </simpara>
		    <simpara>
			Because transit from strict routing to loose routing would break backwards
			compatibility and older user agents wouldn't work, it is necessary to make
			loose routing backwards compatible. The backwards compatibility
			unfortunately adds a lot of overhead and is often source of major problems.
		    </simpara>
		</section>
	    </section>
	    <section id="sec-event-subscription-and-notification">
		<title>Event Subscription And Notification</title>
		<simpara>
		    The &sip; specification has been extended to support a general mechanism allowing
		    subscription to asynchronous events. Such evens can include &sip; proxy statistics
		    changes, presence information, session changes and so on.
		</simpara>
		<simpara>
		    The mechanism is used mainly to convey information on presence (willingness to
		    communicate) of users. <xref linkend="fig-event"> shows the basic message
		    flow.
		</simpara>
		<figure id="fig-event" float="0">
		    <title>Event Subscription And Notification</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/event.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/event.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing subscription and notification.</phrase>
			</textobject>
		    </mediaobject>
		</figure>
		<simpara>
		    A user agent interested in event notification sends a SUBSCRIBE message to a
		    &sip; server. The SUBSCRIBE message establishes a dialog and is immediately
		    replied by the server using 200 OK response. At this point the dialog is
		    established. The server sends a NOTIFY request to the user every time the event
		    to which the user subscribed changes. NOTIFY messages are sent within the dialog
		    established by the SUBSCRIBE.
		</simpara>
		<simpara>
		    Note that the first NOTIFY message in <xref linkend="fig-event"> is sent
			regardless of any event that triggers notifications.
		</simpara>
		<simpara>
		    Subscriptions--as well as registrations--have limited lifespan and therefore must be
		    periodically refreshed.
		</simpara>
	    </section>
	    <section id="sec-instant-messages">
		<title>Instant Messages</title>
		<simpara>
		    Instant messages are sent using MESSAGE request. MESSAGE requests do not establish a
		    dialog and therefore they will always traverse the same set of proxies. This is the
		    simplest form of sending instant messages. The text of the instant message is
		    transported in the body of the &sip; request.
		</simpara>
		<figure id="fig-message" float="0">
		    <title>Instant Messages</title>
		    <mediaobject>
			<imageobject>
			    <imagedata align="center" scale="40" fileref="figures/message.eps" format="EPS">
			</imageobject>
			<imageobject>
			    <imagedata align="center" fileref="figures/message.png" format="PNG">
			</imageobject>
			<textobject>
			    <phrase>Picture showing a MESSAGE.</phrase>
			</textobject>
		    </mediaobject>
		</figure>
	    </section>
	</section>
    </chapter>
</book>