Browse code

- Improved documentation system - documentation makefiles - XML-based dialect of docbook used

Jan Janak authored on 23/07/2005 22:48:53
Showing 1 changed files
1 1
deleted file mode 100644
... ...
@@ -1,1052 +0,0 @@
1
-<!-- $Id$ -->
2
-<!DOCTYPE Book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [
3
-
4
-<!-- Include general SER documentation entities -->
5
-<!ENTITY % serentities SYSTEM "../ser_entities.sgml">
6
-%serentities;
7
-
8
-]>
9
-
10
-<book>
11
-    <bookinfo>
12
-	<title>&sip; Introduction</title>
13
-	<authorgroup>
14
-	    <author>
15
-		<firstname>Jan</firstname>
16
-		<surname>Janak</surname>
17
-		<email>jan@iptel.org</email>
18
-	    </author>
19
-	</authorgroup>
20
-	<copyright>
21
-	    <year>2003</year>
22
-	    <holder>&fhg;</holder>
23
-	</copyright>
24
-	<abstract>
25
-	    <para>
26
-		A brief overview of &sip; describing all important aspects of the Session Initiation
27
-		Protocol.
28
-	    </para>
29
-	</abstract>
30
-    </bookinfo>
31
-    <toc></toc>
32
-
33
-    <chapter>
34
-	<title>&sip; Introduction</title>
35
-	<section id="sec-purpose-of-sip">
36
-	    <title>Purpose of &sip;</title>
37
-	    <simpara>
38
-		&sip; stands for Session Initiation Protocol. It is an application-layer control
39
-		protocol which has been developed and designed within the &ietf;. The protocol has
40
-		been designed with easy implementation, good scalability, and flexibility in mind.
41
-	    </simpara>
42
-	    <simpara>
43
-		The specification is available in form of several <abbrev>RFCs</abbrev>, the most
44
-		important one is &rfc3261; which contains the core protocol specification. The
45
-		protocol is used for creating, modifying, and terminating sessions with one or more
46
-		participants. By sessions we understand a set of senders and receivers that
47
-		communicate and the state kept in those senders and receivers during the
48
-		communication. Examples of a session can include Internet telephone calls,
49
-		distribution of multimedia, multimedia conferences, distributed computer games, etc.
50
-	    </simpara>
51
-	    <simpara>
52
-		&sip; is not the only protocol that the communicating devices will need. It is not
53
-		meant to be a general purpose protocol. Purpose of &sip; is just to make the
54
-		communication possible, the communication itself must be achieved by another means
55
-		(and possibly another protocol). Two protocols that are most often used along with
56
-		&sip; are &rtp; and &sdp;. &rtp; protocol is used to carry the real-time multimedia
57
-		data (including audio, video, and text), the protocol makes it possible to encode
58
-		and split the data into packets and transport such packets over the
59
-		Internet. Another important protocol is &sdp;, which is used to describe and encode
60
-		capabilities of session participants. Such a description is then used to negotiate
61
-		the characteristics of the session so that all the devices can participate (that
62
-		includes, for example, negotiation of codecs used to encode media so all the
63
-		participants will be able to decode it, negotiation of transport protocol used and
64
-		so on).
65
-	    </simpara>
66
-	    <simpara>
67
-		&sip; has been designed in conformance with the Internet model. It is an end-to-end
68
-		oriented signaling protocol which means, that all the logic is stored in end
69
-		devices (except routing of &sip; messages). State is also stored in end-devices
70
-		only, there is no single point of failure and networks designed this way scale
71
-		well. The price that we have to pay for the distributiveness and scalability is
72
-		higher message overhead, caused by the messages being sent end-to-end.
73
-	    </simpara>
74
-	    <simpara>
75
-		It is worth of mentioning that the end-to-end concept of &sip; is a significant
76
-		divergence from regular &pstn; (Public Switched Telephone Network) where all the
77
-		state and logic is stored in the network and end devices (telephones) are very
78
-		primitive. Aim of &sip; is to provide the same functionality that the traditional
79
-		&pstn;s have, but the end-to-end design makes &sip; networks much more powerful and
80
-		open to the implementation of new services that can be hardly implemented in the
81
-		traditional &pstn;s.
82
-	    </simpara>
83
-	    <simpara>
84
-		&sip; is based on &http; protocol. The &http; protocol inherited format of message
85
-		headers from &rfc822;. &http; is probably the most successful and widely used
86
-		protocol in the Internet. It tries to combine the best of the both. In fact, &http;
87
-		can be classified as a signaling protocol too, because user agents use the protocol
88
-		to tell a &http; server in which documents they are interested in. &sip; is used to
89
-		carry the description of session parameters, the description is encoded into a
90
-		document using &sdp;. Both protocols (&http; and &sip;) have inherited encoding of
91
-		message headers from &rfc822;. The encoding has proven to be robust and flexible
92
-		over the years.
93
-	    </simpara>
94
-	</section>
95
-	<section id="sec-sip-uri">
96
-	    <title>&sip; &uri;</title>
97
-	    <simpara>
98
-		&sip; entities are identified using &sip; &uri; (Uniform Resource Identifier). A
99
-		&sip; &uri; has form of sip:username@domain, for instance,
100
-		sip:joe@company.com. As we can see, &sip; &uri; consists of username part and
101
-		domain name part delimited by @ (at) character. &sip; &uri;s are similar to
102
-		e-mail addresses, it is, for instance, possible to use the same &uri; for e-mail
103
-		and &sip; communication, such &uri;s are easy to remember.
104
-	    </simpara>
105
-	</section>
106
-	<section id="sec-sip-network-elements">
107
-	    <title>&sip; Network Elements</title>
108
-	    <simpara>
109
-		Although in the simplest configuration it is possible to use just two user agents
110
-		that send &sip; messages directly to each other, a typical &sip; network will
111
-		contain more than one type of &sip; elements. Basic &sip; elements are user agents,
112
-		proxies, registrars, and redirect servers. We will briefly describe them in this
113
-		section.
114
-	    </simpara>
115
-	    <simpara>
116
-		Note that the elements, as presented in this section, are often only logical
117
-		entities. It is often profitable to co-locate them together, for instance, to
118
-		increase the speed of processing, but that depends on a particular implementation
119
-		and configuration.
120
-	    </simpara>
121
-	    <section id="sec-user-agents">
122
-		<title>User Agents</title>
123
-		<simpara>
124
-		    Internet end points that use &sip; to find each other and to negotiate a session
125
-		    characteristics are called <emphasis>user agents</emphasis>. User agents
126
-		    usually, but not necessarily, reside on a user's computer in form of an
127
-		    application--this is currently the most widely used approach, but user agents
128
-		    can be also cellular phones, &pstn; gateways, <acronym>PDAs</acronym>, automated
129
-		    <acronym>IVR</acronym> systems and so on.
130
-		</simpara>
131
-		<simpara>
132
-		    User agents are often referred to as <emphasis>User Agent Server</emphasis>
133
-		    (&uas;) and <emphasis>User Agent Client</emphasis> (&uac;). &uas; and &uac; are
134
-		    logical entities only, each user agent contains a &uac; and &uas;. &uac; is the
135
-		    part of the user agent that sends requests and receives responses. &uas; is the
136
-		    part of the user agent that receives requests and sends responses.
137
-		</simpara>
138
-		<simpara>
139
-		    Because a user agent contains both &uac; and &uas;, we often say that a user
140
-		    agent behaves like a &uac; or &uas;. For instance, caller's user agent behaves
141
-		    like &uac; when it sends an INVITE requests and receives responses to the
142
-		    request. Callee's user agent behaves like a &uas; when it receives the INVITE
143
-		    and sends responses.
144
-		</simpara>
145
-		<simpara>
146
-		    But this situation changes when the callee decides to send a BYE and terminate
147
-		    the session. In this case the callee's user agent (sending BYE) behaves like
148
-		    &uac; and the caller's user agent behaves like &uas;.
149
-		</simpara>
150
-		<figure id="fig-ua" float="0">
151
-		    <title>&uac; and &uas;</title>		    
152
-		    <mediaobject>
153
-			<imageobject>
154
-			    <imagedata align="center" scale="40" fileref="figures/ua.eps" format="EPS">
155
-			</imageobject>
156
-			<imageobject>
157
-			    <imagedata align="center" fileref="figures/ua.png" format="PNG">
158
-			</imageobject>
159
-			<textobject>
160
-			    <phrase>Picture showing &uac; and &uas;</phrase>
161
-			</textobject>
162
-		    </mediaobject>
163
-		</figure>
164
-		<simpara>
165
-		    <xref linkend="fig-ua"> shows three user agents and one stateful forking
166
-		    proxy. Each user agent contains &uac; and &uas;. The part of the proxy that
167
-		    receives the INVITE from the caller in fact acts as a &uas;. When forwarding the
168
-		    request statefully the proxy creates two &uac;s, each of them is responsible for
169
-		    one branch.
170
-		</simpara>
171
-		<simpara>
172
-		    In our example callee B picked up and later when he wants to tear down the call
173
-		    it sends a BYE. At this time the user agent that was previously &uas; becomes a
174
-		    &uac; and vice versa.
175
-		</simpara>
176
-	    </section>
177
-	    <section id="sec-proxy-servers">
178
-		<title>Proxy Servers</title>
179
-		<simpara>
180
-		    In addition to that &sip; allows creation of an infrastructure of network hosts
181
-		    called <emphasis>proxy servers</emphasis>. User agents can send messages to a
182
-		    proxy server. Proxy servers are very important entities in the &sip;
183
-		    infrastructure. They perform routing of a session invitations according to
184
-		    invitee's current location, authentication, accounting and many other important
185
-		    functions.
186
-		</simpara>
187
-		<simpara>
188
-		    The most important task of a proxy server is to route session invitations
189
-		    <quote>closer</quote> to callee. The session invitation will usually traverse a
190
-		    set of proxies until it finds one which knows the actual location of the
191
-		    callee. Such a proxy will forward the session invitation directly to the callee
192
-		    and the callee will then accept or decline the session invitation.
193
-		</simpara>
194
-		<simpara>
195
-		    There are two basic types of &sip; proxy servers--stateless and stateful.
196
-		</simpara>
197
-
198
-		<section id="sec-stateless-servers">
199
-		    <title>Stateless Servers</title>
200
-		    <simpara>
201
-			Stateless server are simple message forwarders. They forward messages
202
-			independently of each other. Although messages are usually arranged into
203
-			transactions (see <xref linkend="sec-sip-transactions">), stateless proxies
204
-			do not take care of transactions.
205
-		    </simpara>
206
-		    <simpara>
207
-			Stateless proxies are simple, but faster than stateful proxy servers. They
208
-			can be used as simple load balancers, message translators and routers. One
209
-			of drawbacks of stateless proxies is that they are unable to absorb
210
-			retransmissions of messages and perform more advanced routing, for instance,
211
-			forking or recursive traversal.
212
-		    </simpara>
213
-		</section>
214
-		<section id="sec-stateful-servers">
215
-		    <title>Stateful Servers</title>
216
-		    <simpara>
217
-			Stateful proxies are more complex. Upon reception of a request, stateful
218
-			proxies create a state and keep the state until the transaction
219
-			finishes. Some transactions, especially those created by INVITE, can last
220
-			quite long (until callee picks up or declines the call). Because stateful
221
-			proxies must maintain the state for the duration of the transactions, their
222
-			performance is limited.
223
-		    </simpara>
224
-		    <simpara>
225
-			The ability to associate &sip; messages into transactions gives stateful
226
-			proxies some interesting features. Stateful proxies can perform forking,
227
-			that means upon reception of a message two or more messages will be sent
228
-			out.
229
-		    </simpara>
230
-		    <simpara>
231
-			Stateful proxies can absorb retransmissions because they know, from the
232
-			transaction state, if they have already received the same message (stateless
233
-			proxies cannot do the check because they keep no state).
234
-		    </simpara>
235
-		    <simpara>
236
-			Stateful proxies can perform more complicated methods of finding a user. It
237
-			is, for instance, possible to try to reach user's office phone and when he
238
-			doesn't pick up then the call is redirected to his cell phone. Stateless
239
-			proxies can't do this because they have no way of knowing how the
240
-			transaction targeted to the office phone finished.
241
-		    </simpara>
242
-		    <simpara>
243
-			Most &sip; proxies today are stateful because their configuration is usually
244
-			very complex. They often perform accounting, forking, some sort of &nat;
245
-			traversal aid and all those features require a stateful proxy.
246
-		    </simpara>
247
-		</section>
248
-		<section id="sec-proxy-server-usage">
249
-		    <title>Proxy Server Usage</title>
250
-		    <simpara>
251
-			A typical configuration is that each centrally administered entity (a
252
-			company, for instance) has it's own &sip; proxy server which is used by all
253
-			user agents in the entity. Let's suppose that there are two companies A and
254
-			B and each of them has it's own proxy server. <xref linkend="fig-companies">
255
-			shows how a session invitation from employee Joe in company A will reach
256
-			employee Bob in company B.
257
-		    </simpara>
258
-		    <figure id="fig-companies" float="0">
259
-			<title>Session Invitation</title>
260
-			<mediaobject>
261
-			    <imageobject>
262
-				<imagedata align="center" scale="40" fileref="figures/companies.eps" format="EPS">
263
-			    </imageobject>
264
-			    <imageobject>
265
-				<imagedata align="center" fileref="figures/companies.png" format="PNG">
266
-			    </imageobject>
267
-			    <textobject>
268
-				<phrase>Picture showing a session invitation message flow</phrase>
269
-			    </textobject>
270
-			</mediaobject> 
271
-		    </figure>
272
-		    <simpara>
273
-			User Joe uses address sip:bob@b.com to call Bob. Joe's user agent doesn't
274
-			know how to route the invitation itself but it is configured to send all
275
-			outbound traffic to the company &sip; proxy server proxy.a.com. The proxy
276
-			server figures out that user sip:bob@b.com is in a different company so it
277
-			will look up B's &sip; proxy server and send the invitation there. B's proxy
278
-			server can be either pre-configured at proxy.a.com or the proxy will use
279
-			<acronym>DNS SRV</acronym> records to find B's proxy server. The invitation
280
-			reaches proxy.bo.com. The proxy knows that Bob is currently sitting in his
281
-			office and is reachable through phone on his desk, which has &ip; address
282
-			1.2.3.4, so the proxy will send the invitation there.
283
-		    </simpara>
284
-		</section>
285
-	    </section>
286
-	    <section id="sec-registrar">
287
-		<title>Registrar</title>
288
-		<simpara>
289
-		    We mentioned that the &sip; proxy at proxy.b.com knows current Bob's location
290
-		    but haven't mentioned yet how a proxy can learn current location of a
291
-		    user. Bob's user agent (&sip; phone) must register with a
292
-		    <emphasis>registrar</emphasis>. The registrar is a special &sip; entity that
293
-		    receives registrations from users, extracts information about their current
294
-		    location (&ip; address, port and username in this case) and stores the
295
-		    information into location database. Purpose of the location database is to map
296
-		    sip:bob@b.com to something like sip:bob@1.2.3.4:5060. The location database is
297
-		    then used by B's proxy server. When the proxy receives an invitation for
298
-		    sip:bob@b.com it will search the location database. It finds
299
-		    sip:bob@1.2.3.4:5060 and will send the invitation there. A registrar is very
300
-		    often a logical entity only. Because of their tight coupling with proxies
301
-		    registrars, are usually co-located with proxy servers.
302
-		</simpara>
303
-		<simpara>
304
-		    <xref linkend="fig-registrar"> shows a typical &sip; registration. A REGISTER
305
-		    message containing Address of Record sip:jan@iptel.org and contact address
306
-		    sip:jan@1.2.3.4:5060 where 1.2.3.4 is &ip; address of the phone, is sent to the
307
-		    registrar. The registrar extracts this information and stores it into the
308
-		    location database. If everything went well then the registrar sends a 200 OK
309
-		    response to the phone and the process of registration is finished.
310
-		</simpara>
311
-		<figure id="fig-registrar" float="0">
312
-		    <title>Registrar Overview</title>
313
-		    <mediaobject>
314
-			<imageobject>
315
-			    <imagedata align="center" scale="40" fileref="figures/registrar.eps" format="EPS">
316
-			</imageobject>
317
-			<imageobject>
318
-			    <imagedata align="center" fileref="figures/registrar.png" format="PNG">
319
-			</imageobject>
320
-			<textobject>
321
-			    <phrase>Picture showing a typical registrar</phrase>
322
-			</textobject>
323
-		    </mediaobject> 
324
-		</figure>
325
-		<simpara>
326
-		    Each registration has a limited lifespan. Expires header field or expires
327
-		    parameter of Contact header field determines for how long is the registration
328
-		    valid. The user agent must refresh the registration within the lifespan
329
-		    otherwise it will expire and the user will become unavailable.
330
-		</simpara>
331
-	    </section>
332
-	    <section id="sec-redirect-server">
333
-		<title>Redirect Server</title>
334
-		<simpara>
335
-		    The entity that receives a request and sends back a reply containing a list of the
336
-		    current location of a particular user is called <emphasis>redirect server</emphasis>. A
337
-		    redirect server receives requests and looks up the intended recipient of the request in
338
-		    the location database created by a registrar. It then creates a list of current
339
-		    locations of the user and sends it to the request originator in a response within 3xx
340
-		    class.
341
-		</simpara>
342
-		<simpara>
343
-		    The originator of the request then extracts the list of destinations and sends
344
-		    another request directly to them. <xref linkend="fig-redirect"> shows a typical
345
-		    redirection.
346
-		</simpara>
347
-		<figure id="fig-redirect" float="0">
348
-		    <title>&sip; Redirection</title>
349
-		    <mediaobject>
350
-			<imageobject>
351
-			    <imagedata align="center" scale="40" fileref="figures/redirect.eps" format="EPS">
352
-			</imageobject>
353
-			<imageobject>
354
-			    <imagedata align="center" fileref="figures/redirect.png" format="PNG">
355
-			</imageobject>
356
-			<textobject>
357
-			    <phrase>Picture showing a redirection</phrase>
358
-			</textobject>
359
-		    </mediaobject> 
360
-		</figure>
361
-	    </section>
362
-	</section>
363
-	<section id="sec-sip-messages">
364
-	    <title>&sip; Messages</title>
365
-	    <simpara>
366
-		Communication using &sip; (often called signaling) comprises of series of
367
-		<emphasis>messages</emphasis>. Messages can be transported independently by the
368
-		network. Usually they are transported in a separate &udp; datagram each. Each
369
-		message consist of <quote>first line</quote>, message header, and message body. The
370
-		first line identifies type of the message. There are two types of
371
-		messages--<emphasis>requests</emphasis> and <emphasis>responses</emphasis>.
372
-		Requests are usually used to initiate some action or inform recipient of the request
373
-		of something. Replies are used to confirm that a request was received and processed
374
-		and contain the status of the processing.
375
-	    </simpara>
376
-	    <simpara>
377
-		A typical &sip; request looks like this:
378
-	    </simpara>
379
-	<programlisting format="linespecific">
380
-INVITE sip:7170@iptel.org SIP/2.0
381
-Via: SIP/2.0/UDP 195.37.77.100:5040;rport
382
-Max-Forwards: 10
383
-From: "jiri" &lt;sip:jiri@iptel.org&gt;;tag=76ff7a07-c091-4192-84a0-d56e91fe104f
384
-To: &lt;sip:jiri@bat.iptel.org&gt;
385
-Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.20.128.35
386
-CSeq: 2 INVITE
387
-Contact: &lt;sip:213.20.128.35:9315&gt;
388
-User-Agent: Windows RTC/1.0
389
-Proxy-Authorization: Digest username="jiri", realm="iptel.org", 
390
-  algorithm="MD5", uri="sip:jiri@bat.iptel.org", 
391
-  nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c", 
392
-  response="53fe98db10e1074
393
-b03b3e06438bda70f"
394
-Content-Type: application/sdp
395
-Content-Length: 451
396
-
397
-v=0
398
-o=jku2 0 0 IN IP4 213.20.128.35
399
-s=session
400
-c=IN IP4 213.20.128.35
401
-b=CT:1000
402
-t=0 0
403
-m=audio 54742 RTP/AVP 97 111 112 6 0 8 4 5 3 101
404
-a=rtpmap:97 red/8000
405
-a=rtpmap:111 SIREN/16000
406
-a=fmtp:111 bitrate=16000
407
-a=rtpmap:112 G7221/16000
408
-a=fmtp:112 bitrate=24000
409
-a=rtpmap:6 DVI4/16000
410
-a=rtpmap:0 PCMU/8000
411
-a=rtpmap:4 G723/8000
412
-a=rtpmap: 3 GSM/8000
413
-a=rtpmap:101 telephone-event/8000
414
-a=fmtp:101 0-16
415
-</programlisting>
416
-	    <simpara>
417
-		The first line tells us that this is INVITE message which is used to establish a
418
-		session. The &uri; on the first line--sip:7170@iptel.org is called <emphasis>Request
419
-		&uri;</emphasis> and contains &uri; of the next hop of the message. In this case it
420
-		will be host iptel.org.
421
-	    </simpara>
422
-	    <simpara>
423
-		A &sip; request can contain one or more Via header fields which are used to record
424
-		path of the request. They are later used to route &sip; responses exactly the same
425
-		way. The INVITE message contains just one Via header field which was created by the
426
-		user agent that sent the request. From the Via field we can tell that the user agent
427
-		is running on host 195.37.77.100 and port 5060.
428
-	    </simpara>
429
-	    <simpara>
430
-		From and To header fields identify initiator (caller) and recipient (callee) of the
431
-		invitation (just like in &smtp; where they identify sender and recipient of a
432
-		message). From header field contains a tag parameter which serves as a dialog
433
-		identifier and will be described in <xref linkend="sec-sip-dialogs">.
434
-	    </simpara>
435
-	    <simpara>
436
-		Call-ID header field is a dialog identifier and it's purpose is to identify messages
437
-		belonging to the same call. Such messages have the same Call-ID identifier. CSeq is
438
-		used to maintain order of requests. Because requests can be sent over an unreliable
439
-		transport that can re-order messages, a sequence number must be present in the
440
-		messages so that recipient can identify retransmissions and out of order requests.
441
-	    </simpara>
442
-	    <simpara>
443
-		Contact header field contains &ip; address and port on which the sender is awaiting
444
-		further requests sent by callee. Other header fields are not important and will be
445
-		not described here.
446
-	    </simpara>
447
-	    <simpara>
448
-		Message header is delimited from message body by an empty line. Message body of the INVITE
449
-		request contains a description of the media type accepted by the sender and encoded in
450
-		&sdp;.
451
-	    </simpara>
452
-	    <section id="sec-sip-requests">
453
-		<title>&sip; Requests</title>
454
-		<simpara>
455
-		    We have described how an INVITE request looks like and said that the request is
456
-		    used to invite a callee to a session. Other important requests are:
457
-		</simpara>
458
-		<itemizedlist>
459
-		    <listitem>
460
-			<simpara>
461
-			    <emphasis>ACK</emphasis>--This message acknowledges receipt of a final
462
-			    response to INVITE. Establishing of a session utilizes 3-way
463
-			    hand-shaking due to asymmetric nature of the invitation. It may take a
464
-			    while before the callee accepts or declines the call so the callee's
465
-			    user agent periodically retransmits a positive final response until it
466
-			    receives an ACK (which indicates that the caller is still there and
467
-			    ready to communicate).
468
-			</simpara>
469
-		    </listitem>
470
-		    <listitem>
471
-			<simpara>
472
-			    <emphasis>BYE</emphasis>--Bye messages are used to tear down multimedia
473
-			    sessions. A party wishing to tear down a session sends a BYE to the
474
-			    other party.
475
-			</simpara>
476
-		    </listitem>
477
-		    <listitem>
478
-			<simpara>
479
-			    <emphasis>CANCEL</emphasis>--Cancel is used to cancel not yet fully
480
-			    established session. It is used when the callee hasn't replied with a
481
-			    final response yet but the caller wants to abort the call (typically
482
-			    when a callee doesn't respond for some time).
483
-			</simpara>
484
-		    </listitem>
485
-		    <listitem>
486
-			<simpara>
487
-			    <emphasis>REGISTER</emphasis>--Purpose of REGISTER request is to let
488
-			    registrar know of current user's location. Information about current
489
-			    &ip; address and port on which a user can be reached is carried in
490
-			    REGISTER messages. Registrar extracts this information and puts it into
491
-			    a location database. The database can be later used by &sip; proxy
492
-			    servers to route calls to the user. Registrations are time-limited and
493
-			    need to be periodically refreshed.
494
-			</simpara>
495
-		    </listitem>
496
-		</itemizedlist>
497
-		<simpara>
498
-		    The listed requests usually have no message body because it is not needed in
499
-		    most situations (but can have one). In addition to that many other request types
500
-		    have been defined but their description is out of the scope of this document.
501
-		</simpara>
502
-	    </section>
503
-	    <section id="sec-sip-responses">
504
-		<title>&sip; Responses</title>
505
-		<simpara>
506
-		    When a user agent or proxy server receives a request it send a reply. Each
507
-		    request must be replied except ACK requests which trigger no replies.
508
-		</simpara>
509
-		<simpara>
510
-		    A typical reply looks like this:
511
-		</simpara>
512
-		<programlisting format="linespecific">
513
-SIP/2.0 200 OK
514
-Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68
515
-From: sip:sip2@iptel.org
516
-To: sip:sip2@iptel.org;tag=794fe65c16edfdf45da4fc39a5d2867c.b713
517
-Call-ID: 2443936363@192.168.1.30
518
-CSeq: 63629 REGISTER
519
-Contact: &lt;sip:sip2@66.87.48.68:5060;transport=udp&gt;;q=0.00;expires=120
520
-Server: Sip EXpress router (0.8.11pre21xrc (i386/linux))
521
-Content-Length: 0
522
-Warning: 392 195.37.77.101:5060 "Noisy feedback tells:  
523
-    pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org 
524
-    out_uri=sip:iptel.org via_cnt==1"
525
-</programlisting>
526
-		<simpara>
527
-		    As we can see, responses are very similar to the requests, except for the first
528
-		    line. The first line of response contains protocol version (SIP/2.0), reply
529
-		    code, and reason phrase.
530
-		</simpara>
531
-		<simpara>
532
-		    The <emphasis>reply code</emphasis> is an integer number from 100 to 699 and
533
-		    indicates type of the response. There are 6 classes of responses:
534
-		</simpara>
535
-		<itemizedlist>
536
-		    <listitem>
537
-			<simpara>
538
-			    <emphasis>1xx</emphasis> are <emphasis>provisional</emphasis>
539
-			    responses. A provisional response is response that tells to its
540
-			    recipient that the associated request was received but result of the
541
-			    processing is not known yet. Provisional responses are sent only when
542
-			    the processing doesn't finish immediately. The sender must stop
543
-			    retransmitting the request upon reception of a provisional response.
544
-			</simpara>
545
-			<simpara>
546
-			    Typically proxy servers send responses with code 100 when they start
547
-			    processing an INVITE and user agents send responses with code 180
548
-			    (Ringing) which means that the callee's phone is ringing.
549
-			</simpara>
550
-		    </listitem>
551
-		    <listitem>
552
-			<simpara>
553
-			    <emphasis>2xx</emphasis> responses are <emphasis>positive
554
-			    final</emphasis> responses. A final response is the ultimate response
555
-			    that the originator of the request will ever receive. Therefore final
556
-			    responses express result of the processing of the associated
557
-			    request. Final responses also terminate transactions. Responses with
558
-			    code from 200 to 299 are positive responses that means that the request
559
-			    was processed successfully and accepted. For instance a 200 OK response
560
-			    is sent when a user accepts invitation to a session (INVITE request).
561
-			</simpara>
562
-			<simpara>
563
-			    A &uac; may receive several 200 messages to a single INVITE
564
-			    request. This is because a forking proxy (described later) can fork the
565
-			    request so it will reach several &uas; and each of them will accept the
566
-			    invitation. In this case each response is distinguished by the tag
567
-			    parameter in To header field. Each response represents a distinct dialog
568
-			    with unambiguous dialog identifier.
569
-			</simpara>
570
-		    </listitem>
571
-		    <listitem>
572
-			<simpara>
573
-			    <emphasis>3xx</emphasis> responses are used to redirect a caller. A
574
-			    redirection response gives information about the user's new location or
575
-			    an alternative service that the caller might use to satisfy the
576
-			    call. Redirection responses are usually sent by proxy servers. When a
577
-			    proxy receives a request and doesn't want or can't process it for any
578
-			    reason, it will send a redirection response to the caller and put
579
-			    another location into the response which the caller might want to
580
-			    try. It can be the location of another proxy or the current location of
581
-			    the callee (from the location database created by a registrar). The
582
-			    caller is then supposed to re-send the request to the new location. 3xx
583
-			    responses are final.
584
-			</simpara>
585
-		    </listitem>
586
-		    <listitem>
587
-			<simpara>
588
-			    <emphasis>4xx</emphasis> are <emphasis>negative final</emphasis>
589
-			    responses. a 4xx response means that the problem is on the sender's
590
-			    side. The request couldn't be processed because it contains bad syntax
591
-			    or cannot be fulfilled at that server.
592
-			</simpara>
593
-		    </listitem>
594
-		    <listitem>
595
-			<simpara>
596
-			    <emphasis>5xx</emphasis> means that the problem is on server's side. The
597
-			    request is apparently valid but the server failed to fulfill it. Clients
598
-			    should usually retry the request later.
599
-			</simpara>
600
-		    </listitem>
601
-		    <listitem>
602
-			<simpara>
603
-			    <emphasis>6xx</emphasis> reply code means that the request cannot be
604
-			    fulfilled at any server. This response is usually sent by a server that
605
-			    has definitive information about a particular user. User agents usually
606
-			    send a 603 Decline response when the user doesn't want to participate in
607
-			    the session.
608
-			</simpara>
609
-		    </listitem>
610
-		</itemizedlist>
611
-		<simpara>
612
-		    In addition to the response class the first line also contains <emphasis>reason
613
-			phrase</emphasis>. The code number is intended to be processed by
614
-		    machines. It is not very human-friendly but it is very easy to parse and
615
-		    understand by machines. The reason phrase usually contains a human-readable
616
-		    message describing the result of the processing. A user agent should render
617
-		    the reason phrase to the user.
618
-		</simpara>
619
-		<simpara>
620
-		    The request to which a particular response belongs is identified using the CSeq
621
-		    header field. In addition to the sequence number this header field also contains
622
-		    method of corresponding request. In our example it was REGISTER request.
623
-		</simpara>
624
-	    </section>
625
-	</section> 
626
-	<section id="sec-sip-transactions">
627
-	    <title>&sip; Transactions</title>
628
-	    <simpara>
629
-		Although we said that &sip; messages are sent independently over the network, they
630
-		are usually arranged into <emphasis>transactions</emphasis> by user agents and
631
-		certain types of proxy servers. Therefore &sip; is said to be a
632
-		<emphasis>transactional protocol</emphasis>.
633
-	    </simpara>
634
-	    <simpara>
635
-		A transaction is a sequence of &sip; messages exchanged between &sip; network
636
-		elements. A transaction consists of one request and all responses to that
637
-		request. That includes zero or more provisional responses and one or more final
638
-		responses (remember that an INVITE might be answered by more than one final response
639
-		when a proxy server forks the request).
640
-	    </simpara>
641
-	    <simpara>
642
-		If a transaction was initiated by an INVITE request then the same transaction also
643
-		includes ACK, but only if the final response was not a 2xx response. If the final
644
-		response was a 2xx response then the ACK is not considered part of the transaction.
645
-	    </simpara>
646
-	    <simpara>
647
-		As we can see this is quite asymmetric behavior--ACK is part of transactions with a
648
-		negative final response but is not part of transactions with positive final
649
-		responses. The reason for this separation is the importance of delivery of all 200
650
-		OK messages. Not only that they establish a session, but also 200 OK can be
651
-		generated by multiple entities when a proxy server forks the request and all of them
652
-		must be delivered to the calling user agent. Therefore user agents take
653
-		responsibility in this case and retransmit 200 OK responses until they receive an
654
-		ACK. Also note that only responses to INVITE are retransmitted !
655
-	    </simpara>
656
-	    <simpara>
657
-		&sip; entities that have notion of transactions are called
658
-		<emphasis>stateful</emphasis>. Such entities usually create a state associated with
659
-		a transaction that is kept in the memory for the duration of the transaction. When a
660
-		request or response comes, a stateful entity tries to associate the request (or
661
-		response) to existing transactions. To be able to do it it must extract a unique
662
-		transaction identifier from the message and compare it to identifiers of all
663
-		existing transactions. If such a transaction exists then it's state gets updated
664
-		from the message.
665
-	    </simpara>
666
-	    <simpara>
667
-		In the previous &sip; &rfc2543; the transaction identifier was calculated as hash of
668
-		all important message header fields (that included To, From, Request-URI and
669
-		CSeq). This proved to be very slow and complex, during interoperability tests such
670
-		transaction identifiers used to be a common source of problems.
671
-	    </simpara>
672
-	    <simpara>
673
-		In the new &rfc3261; the way of calculating transaction identifiers was completely
674
-		changed. Instead of complicated hashing of important header fields a &sip; message now
675
-		includes the identifier directly. Branch parameter of Via header fields contains directly
676
-		the transaction identifier. This is significant simplification, but there still exist old
677
-		implementations that don't support the new way of calculating of transaction identifier so
678
-		even new implementations have to support the old way. They must be backwards compatible.
679
-	    </simpara>
680
-	    <simpara>
681
-		<xref linkend="fig-transactions"> shows what messages belong to what transactions
682
-		during a conversation of two user agents.
683
-	    </simpara>
684
-	    <figure id="fig-transactions" float="0">
685
-		<title>&sip; Transactions</title>
686
-		<mediaobject>
687
-		    <imageobject>
688
-			<imagedata align="center" scale="40" fileref="figures/transaction.eps" format="EPS">
689
-		    </imageobject>
690
-		    <imageobject>
691
-			<imagedata align="center" fileref="figures/transaction.png" format="PNG">
692
-		    </imageobject>
693
-		    <textobject>
694
-			<phrase>Message flow showing messages belonging to the same transaction.</phrase>
695
-		    </textobject>
696
-		</mediaobject>
697
-	    </figure>
698
-	</section>
699
-	<section id="sec-sip-dialogs">
700
-	    <title>&sip; Dialogs</title>
701
-	    <simpara>
702
-		We have shown what transactions are, that one transaction includes INVITE and it's
703
-		responses and another transaction includes BYE and it responses when a session is
704
-		being torn down. But we feel that those two transactions should be somehow
705
-		related--both of them belong to the same <emphasis>dialog</emphasis>. A dialog
706
-		represents a peer-to-peer &sip; relationship between two user agents. A dialog
707
-		persists for some time and it is very important concept for user agents. Dialogs
708
-		facilitate proper sequencing and routing of messages between &sip; endpoints.
709
-	    </simpara>
710
-	    <simpara>
711
-		Dialogs are identified using Call-ID, From tag, and To tag. Messages that have these
712
-		three identifiers same belong to the same dialog. We have shown that CSeq header
713
-		field is used to order messages, in fact it is used to order messages within a
714
-		dialog. The number must be monotonically increased for each message sent within a
715
-		dialog otherwise the peer will handle it as out of order request or
716
-		retransmission. In fact, the CSeq number identifies a transaction within a dialog
717
-		because we have said that requests and associated responses are called
718
-		transaction. This means that only one transaction in each direction can be active
719
-		within a dialog. One could also say that a <emphasis>dialog is a sequence of
720
-		transactions</emphasis>. <xref linkend="fig-dialog"> extends <xref
721
-		linkend="fig-transactions"> to show which messages belong to the same dialog.
722
-	    </simpara>
723
-	    <figure id="fig-dialog" float="0">
724
-		<title>&sip; Dialog</title>
725
-		<mediaobject>
726
-		    <imageobject>
727
-			<imagedata align="center" scale="40" fileref="figures/dialog.eps" format="EPS">
728
-		    </imageobject>
729
-		    <imageobject>
730
-			<imagedata align="center" fileref="figures/dialog.png" format="PNG">
731
-		    </imageobject>
732
-		    <textobject>
733
-			<phrase>Message flow showing transactions belonging to the same dialog.</phrase>
734
-		    </textobject>
735
-		</mediaobject>
736
-	    </figure>
737
-	    <simpara>
738
-		Some messages establish a dialog and some do not. This allows to explicitly express
739
-		the relationship of messages and also to send messages that are not related to other
740
-		messages outside a dialog. That is easier to implement because user agent don't have
741
-		to keep the dialog state.
742
-	    </simpara>
743
-	    <simpara>
744
-		For instance, INVITE message establishes a dialog, because it will be later followed
745
-		by BYE request which will tear down the session established by the INVITE. This BYE
746
-		is sent within the dialog established by the INVITE.
747
-	    </simpara>
748
-	    <simpara>
749
-		But if a user agent sends a MESSAGE request, such a request doesn't establish any
750
-		dialog. Any subsequent messages (even MESSAGE) will be sent independently of the
751
-		previous one.
752
-	    </simpara>
753
-	    <section id="sec-dialogs-facilitate-routing">
754
-		<title>Dialogs Facilitate Routing</title>
755
-		<simpara>
756
-		    We have said that dialogs are also used to route the messages between user
757
-		    agents, let's describe this a little bit.
758
-		</simpara>
759
-		<simpara>
760
-		    Let's suppose that user sip:bob@a.com wants to talk to user sip:pete@b.com. He
761
-		    knows &sip; address of the callee (sip:pete@b.com) but this address doesn't say
762
-		    anything about current location of the user--i.e. the caller doesn't know to
763
-		    which host to send the request. Therefore the INVITE request will be sent to a
764
-		    proxy server.
765
-		</simpara>
766
-		<simpara>
767
-		    The request will be sent from proxy to proxy until it reaches one that knows
768
-		    current location of the callee. This process is called routing. Once the request
769
-		    reaches the callee, the callee's user agent will create a response that will be
770
-		    sent back to the caller. Callee's user agent will also put Contact header field
771
-		    into the response which will contain the current location of the user. The
772
-		    original request also contained Contact header field which means that both user
773
-		    agents know the current location of the peer.
774
-		</simpara>
775
-		<simpara>
776
-		    Because the user agents know location of each other, it is not necessary to send
777
-		    further requests to any proxy--they can be sent directly from user agent to user
778
-		    agent. That's exactly how dialogs facilitate routing.
779
-		</simpara>
780
-		<simpara>
781
-		    Further messages within a dialog are sent directly from user agent to user
782
-		    agent. This is a significant performance improvement because proxies do not see
783
-		    all the messages within a dialog, they are used to route just the first request
784
-		    that establishes the dialog. The direct messages are also delivered with much
785
-		    smaller latency because a typical proxy usually implements complex routing
786
-		    logic. <xref linkend="fig-trapezoid"> contains an example of a message
787
-		    within a dialog (BYE) that bypasses the proxies.
788
-		</simpara>
789
-		<figure id="fig-trapezoid" float="0">
790
-		    <title>&sip; Trapezoid</title>
791
-		    <mediaobject>
792
-			<imageobject>
793
-			    <imagedata align="center" scale="40" fileref="figures/trapezoid.eps" format="EPS">
794
-			</imageobject>
795
-			<imageobject>
796
-			    <imagedata align="center" fileref="figures/trapezoid.png" format="PNG">
797
-			</imageobject>
798
-			<textobject>
799
-			    <phrase>Message flow showing &sip; trapezoid.</phrase>
800
-			</textobject>
801
-		    </mediaobject>
802
-		</figure>
803
-	    </section>
804
-	    <section id="sec-dialog-identifiers">
805
-		<title>Dialog Identifiers</title>
806
-		<simpara>
807
-		    We have already shown that dialog identifiers consist of three parts, Call-Id,
808
-		    From tag, and To tag, but it is not that clear why are dialog identifiers
809
-		    created exactly this way and who contributes which part.
810
-		</simpara>
811
-		<simpara>
812
-		    Call-ID is so called <emphasis>call identifier</emphasis>. It must be a unique
813
-		    string that identifies a call. A call consists of one or more dialogs. Multiple
814
-		    user agents may respond to a request when a proxy along the path forks the
815
-		    request. Each user agent that sends a 2xx establishes a separate dialog with the
816
-		    caller. All such dialogs are part of the same call and have the same Call-ID.
817
-		</simpara>
818
-		<simpara>
819
-		    From tag is generated by the caller and it uniquely identifies the dialog in the
820
-		    caller's user agent.
821
-		</simpara>
822
-		<simpara>
823
-		    To tag is generated by a callee and it uniquely identifies, just like From tag,
824
-		    the dialog in the callee's user agent.
825
-		</simpara>
826
-		<simpara>
827
-		    This hierarchical dialog identifier is necessary because a single call
828
-		    invitation can create several dialogs and caller must be able to distinguish
829
-		    them.
830
-		</simpara>
831
-	    </section>
832
-	</section>
833
-	<section id="sec-typical-sip-scenarios">
834
-	    <title>Typical &sip; Scenarios</title>
835
-	    <simpara>
836
-		This section gives a brief overview of typical &sip; scenarios that usually make up the
837
-		&sip; traffic.
838
-	    </simpara>
839
-	    <section id="sec-registration">
840
-		<title>Registration</title>
841
-		<simpara>
842
-		    Users must register themselves with a registrar to be reachable by other
843
-		    users. A registration comprises a REGISTER message followed by a 200 OK sent by
844
-		    registrar if the registration was successful. Registrations are usually
845
-		    authorized so a 407 reply can appear if the user didn't provide valid
846
-		    credentials. <xref linkend="fig-register"> shows an example of registration.
847
-		</simpara>
848
-		<figure id="fig-register" float="0">
849
-		    <title>REGISTER Message Flow</title>
850
-		    <mediaobject>
851
-			<imageobject>
852
-			    <imagedata align="center" scale="40" fileref="figures/register.eps" format="EPS">
853
-			</imageobject>
854
-			<imageobject>
855
-			    <imagedata align="center" fileref="figures/register.png" format="PNG">
856
-			</imageobject>
857
-			<textobject>
858
-			    <phrase>Message flow of a registration.</phrase>
859
-			</textobject>
860
-		    </mediaobject>
861
-		</figure>
862
-	    </section>
863
-	    <section id="sec-session-invitation">
864
-		<title>Session Invitation</title>
865
-		<simpara>
866
-		    A session invitation consists of one INVITE request which is usually sent to a
867
-		    proxy. The proxy sends immediately a 100 Trying reply to stop retransmissions
868
-		    and forwards the request further.
869
-		</simpara>
870
-		<simpara>
871
-		    All provisional responses generated by callee are sent back to the caller. See
872
-		    180 Ringing response in the call flow. The response is generated when callee's
873
-		    phone starts ringing.
874
-		</simpara>
875
-		<figure id="fig-invite1" float="0">
876
-		    <title>INVITE Message Flow</title>
877
-		    <mediaobject>
878
-			<imageobject>
879
-			    <imagedata align="center" scale="40" fileref="figures/invite1.eps" format="EPS">
880
-			</imageobject>
881
-			<imageobject>
882
-			    <imagedata align="center" fileref="figures/invite1.png" format="PNG">
883
-			</imageobject>
884
-			<textobject>
885