15cebdfb77e3efcd203f6743164c2f06a474db88
[sip-router] / doc / sip / sip_introduction.sgml
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 signalling 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 signalling 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 reffered 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 preconfigured 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 signalling) 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; aaddress 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                             <phrase>Picture showing a session invitation.</phrase>
886                         </textobject>
887                     </mediaobject>
888                 </figure>
889                 <simpara>
890                     A 200 OK is generated once the callee picks up the phone and it is retransmitted
891                     by the callee's user agent until it receives an ACK from the caller. The session
892                     is established at this point.
893                 </simpara>
894             </section>
895             <section id="sec-session-termination">
896                 <title>Session Termination</title>
897                 <simpara>
898                     Session termination is accomplished by sending a BYE request within dialog
899                     established bye INVITE. BYE messages are sent directly from one user agent to
900                     the other unless a proxy on the path of the INVITE request indicated that it
901                     wishes to stay on the path by using record routing (see <xref
902                     linkend="sec-record-routing">.
903                 </simpara>
904                 <simpara>
905                     Party wishing to tear down a session sends a BYE request to the other party
906                     involved in the session. The other party sends a 200 OK response to confirm the
907                     BYE and the session is terminated. See <xref linkend="fig-bye">, left message
908                     flow.
909                 </simpara>
910             </section>
911             <section id="sec-record-routing">
912                 <title>Record Routing</title>
913                 <simpara>
914                     All requests sent within a dialog are by default sent directly from one user agent
915                     to the other. Only requests outside a dialog traverse &sip; proxies. This approach
916                     makes &sip; network more scalable because only a small number of &sip; messages hit
917                     the proxies.
918                 </simpara>
919                 <simpara>
920                     There are certain situations in which a &sip; proxy need to stay on the path of all
921                     further messages. For instance, proxies controlling a &nat; box or proxies doing
922                     accounting need to stay on the path of BYE requests.
923                 </simpara>
924                 <simpara>
925                     Mechanism by which a proxy can inform user agents that it wishes to stay on the path
926                     of all further messages is called <emphasis>record routing</emphasis>. Such a proxy
927                     would insert Record-Route header field into &sip; messages which contain address of
928                     the proxy. Messages sent within a dialog will then traverse all &sip; proxies that
929                     put a Record-Route header field into the message.
930                 </simpara>
931                 <simpara>
932                     The recipient of the request receives a set of Record-Route header fields in the
933                     message. It must mirror all the Record-Route header fields into responses because
934                     the originator of the request also needs to know the set of proxies.
935                 </simpara>
936                 <figure id="fig-bye" float="0">
937                     <title>BYE Message Flow (With and without Record Routing)</title>
938                     <mediaobject>
939                         <imageobject>
940                             <imagedata align="center" scale="40" fileref="figures/bye.eps" format="EPS">
941                         </imageobject>
942                         <imageobject>
943                             <imagedata align="center" fileref="figures/bye.png" format="PNG">
944                         </imageobject>
945                         <textobject>
946                             <phrase>Picture showing BYE message flow with and without record routing.</phrase>
947                         </textobject>
948                     </mediaobject>
949                 </figure>
950                 <simpara>
951                     Left message flow of <xref linkend="fig-bye"> show how a BYE (request
952                     within dialog established by INVITE) is sent directly to the other user agent
953                     when there is no Record-Route header field in the message. Right message flow
954                     show how the situation changes when the proxy puts a Record-Route header field
955                     into the message.
956                 </simpara>
957                 <section>
958                     <title>Strict versus Loose Routing</title>
959                     <simpara>
960                         The way how record routing works has evolved. Record routing according to
961                         &rfc2643; rewrote the Request-URI. That means the Request-URI always
962                         contained &uri; of the next hop (which can be either next proxy server which
963                         inserted Record-Route header field or destination user agent). Because of
964                         that it was necesarry to save the original Request-URI as the last Route
965                         header field. This approach is called <emphasis>strict routing</emphasis>.
966                     </simpara>
967                     <simpara>
968                         <emphasis>Loose routing</emphasis>, as specified in &rfc3261;, works in a
969                         little bit different way. The Request-URI is no more overwritten, it always
970                         contains &uri; of the destination user agent. If there are any Route header
971                         field in a message, than the message is sent to the &uri; from the topmost
972                         Route header field. This is significant change--Request-URI doesn't
973                         necessarily contain &uri to which the request will be sent. In fact, loose
974                         routing is very similar to IP source routing.
975                     </simpara>
976                     <simpara>
977                         Because transit from strict routing to loose routing would break backwards
978                         compatibility and older user agents wouldn't work, it is necesarry to make
979                         loose routing backwards compatible. The backwards compatibility
980                         unfortunately adds a lot of overhead and is often source of major problems.
981                     </simpara>
982                 </section>
983             </section>
984             <section id="sec-event-subscription-and-notification">
985                 <title>Event Subscription And Notification</title>
986                 <simpara>
987                     The &sip; specification has been extended to support a general mechanism allowing
988                     subscription to asynchronous events. Such evens can include &sip; proxy statistics
989                     changes, presence information, session changes and so on.
990                 </simpara>
991                 <simpara>
992                     The mechanism is used mainly to convey information on presence (willingness to
993                     communicate) of users. <xref linkend="fig-event"> shows the basic message
994                     flow.
995                 </simpara>
996                 <figure id="fig-event" float="0">
997                     <title>Event Subscription And Notification</title>
998                     <mediaobject>
999                         <imageobject>
1000                             <imagedata align="center" scale="40" fileref="figures/event.eps" format="EPS">
1001                         </imageobject>
1002                         <imageobject>
1003                             <imagedata align="center" fileref="figures/event.png" format="PNG">
1004                         </imageobject>
1005                         <textobject>
1006                             <phrase>Picture showing subscription and notification.</phrase>
1007                         </textobject>
1008                     </mediaobject>
1009                 </figure>
1010                 <simpara>
1011                     A user agent interested in event notification sends a SUBSCRIBE message to a
1012                     &sip; server. The SUBSCRIBE message establishes a dialog and is immediately
1013                     replied by the server using 200 OK response. At this point the dialog is
1014                     established. The server sends a NOTIFY request to the user every time the event
1015                     to which the user subscribed changes. NOTIFY messages are sent within the dialog
1016                     established by the SUBSCRIBE.
1017                 </simpara>
1018                 <simpara>
1019                     Note that the first NOTIFY message in <xref linkend="fig-event"> is sent
1020                         regardless of any event that triggers notifications.
1021                 </simpara>
1022                 <simpara>
1023                     Subscriptions--as well as registrations--have limited lifespan and therefore must be
1024                     periodically refreshed.
1025                 </simpara>
1026             </section>
1027             <section id="sec-instant-messages">
1028                 <title>Instant Messages</title>
1029                 <simpara>
1030                     Instant messages are sent using MESSAGE request. MESSAGE requests do not establish a
1031                     dialog and therefore they will always traverse the same set of proxies. This is the
1032                     simplest form of sending instant messages. The text of the instant message is
1033                     transported in the body of the &sip; request.
1034                 </simpara>
1035                 <figure id="fig-message" float="0">
1036                     <title>Instant Messages</title>
1037                     <mediaobject>
1038                         <imageobject>
1039                             <imagedata align="center" scale="40" fileref="figures/message.eps" format="EPS">
1040                         </imageobject>
1041                         <imageobject>
1042                             <imagedata align="center" fileref="figures/message.png" format="PNG">
1043                         </imageobject>
1044                         <textobject>
1045                             <phrase>Picture showing a MESSAGE.</phrase>
1046                         </textobject>
1047                     </mediaobject>
1048                 </figure>
1049             </section>
1050         </section>
1051     </chapter>
1052 </book>