You are on page 1of 22

SIP Introduction

Jan Janak

SIP Introduction
by Jan Janak
Copyright © 2003 FhG FOKUS

A brief overview of SIP describing all important aspects of the Session Initiation Protocol.

....................................... 2 1........................... Session Termination........................ Session Invitation..............................................3...........................................................................5.................... 7 1..................1...........................................................................................4........................................................ 8 1........................ 1 1................................. Record Routing..............................................................................................2........ Typical SIP Scenarios............................................................ Purpose of SIP ..............6. 15 1................7.......3.............................3............4..........7...................3.........6....... 1 1..... SIP Transactions................................................... Registrar................................................7..............................2................. SIP Network Elements ........................................................................................1..................................................1.......................7...........6............................ Registration...... 15 1.......3................................................................2........................................ 9 1........................................................1....................................Table of Contents 1..................2................................. SIP URI ... Redirect Server .........................................................6..... Proxy Servers................... 14 1..... SIP Dialogs..................... 16 1.................................................... User Agents ........................................... 12 1....................................................... 2 1.......... 14 1.......................................................................................................................... Instant Messages.................... 14 1........................7...................................................... Dialogs Facilitate Routing .................3.................................................................. SIP Messages.............. SIP Introduction.................7.................. 13 1..........4.. 5 1.......................2...... 13 1............................................................................. Event Subscription And Notification... 10 1...... SIP Responses.............................................................7......................................... 17 iii ........1...............................................................................................4............ 6 1............................................................................................ 1 1.......................................... 3 1.............................................................................................................................................5..................................................................4..3.......................................................................................................................................... SIP Requests . Dialog Identifiers ....................

...... SIP Transactions .................................................................. SIP Dialog................................................................... 5 1-4................... Session Invitation............................... 17 iv ................................ 12 1-7.................................................................................... SIP Redirection..... 11 1-6............... SIP Trapezoid .................................................... 4 1-3....................................................... 15 1-10.......... 16 1-11......................................................................................... 2 1-2......................................................................................................................................................................................................................................................................................................... BYE Message Flow (With and without Record Routing) .... 16 1-12........ INVITE Message Flow............. 13 1-8....................................List of Figures 1-1................................................................ REGISTER Message Flow ......................................................................................................... Event Subscription And Notification................... 14 1-9........................................................................................................................................................................................................................................................... UAC and UAS ............................................... 6 1-5................................................. Instant Messages................................................................ Registrar Overview.................................................................................................................

caused by the messages being sent end-to-end. The specification is available in form of several RFCs.ietf. The price that we have to pay for the distributiveness and scalability is higher message overhead. modifying.ietf. the most important one is RFC3261 (http://www. distribution of multimedia. Examples of a session can include Internet telephone calls. negotiation of codecs used to encode media so all the participants will be able to decode it. SIP Introduction 1. Another important protocol is SDP.txt) which contains the core protocol specification.org/rfc/rfc822. and terminating sessions with one or more participants. the communication itself must be achieved by another means (and possibly another protocol). the description is encoded into a document using SDP. SIP is not the only protocol that the communicating devices will need.ietf. Two protocols that are most often used along with SIP are RTP and SDP. It is not meant to be a general purpose protocol.org/rfc/rfc822. State is also stored in end-devices only. SIP is based on HTTP protocol. RTP protocol is used to carry the real-time multimedia data (including audio. By sessions we understand a set of senders and receivers that communicate and the state kept in those senders and receivers during the communication.Chapter 1. Purpose of SIP SIP stands for Session Initiation Protocol. The protocol is used for creating.txt). there is no single point of failure and networks designed this way scale well. and flexibility in mind. HTTP can be classified as a signalling protocol too. etc. It is an end-to-end oriented signalling protocol which means. Aim of SIP is to provide the same functionality that the traditional PSTNs have.txt).org). It is worth of mentioning that the end-to-end concept of SIP is a significant divergence from regular PSTN (Public Switched Telephone Network) where all the state and logic is stored in the network and end devices (telephones) are very primitive. The HTTP protocol inherited format of message headers from RFC822 (http://www.1. 1 . multimedia conferences. and text). It tries to combine the best of the both.org/rfc/rfc3261. It is an application-layer control protocol which has been developed and designed within the IETF (http://www. because user agents use the protocol to tell a HTTP server in which documents they are interested in. negotiation of transport protocol used and so on). for example. Such a description is then used to negotiate the characteristics of the session so that all the devices can participate (that includes. SIP has been designed in conformance with the Internet model. Both protocols (HTTP and SIP) have inherited encoding of message headers from RFC822 (http://www. The encoding has proven to be robust and flexible over the years. video. good scalability. Purpose of SIP is just to make the communication possible. SIP is used to carry the description of session parameters. The protocol has been designed with easy implementation. HTTP is probably the most successful and widely used protocol in the Internet. but the end-to-end design makes SIP networks much more powerful and open to the implementation of new services that can be hardly implemented in the traditional PSTNs. the protocol makes it possible to encode and split the data into packets and transport such packets over the Internet.ietf. which is used to describe and encode capabilities of session participants. that all the logic is stored in end devices (except routing of SIP messages). distributed computer games. In fact.

User agents are often reffered to as User Agent Server (UAS) and User Agent Client (UAC). Basic SIP elements are user agents. SIP URIs are similar to e-mail addresses. but not necessarily. are often only logical entities. 1. User agents usually. SIP URI SIP entities are identified using SIP URI (Uniform Resource Identifier). SIP URI consists of username part and domain name part delimited by @ (at) character. but user agents can be also cellular phones. UAS is the part of the user agent that receives requests and sends responses. UAC is the part of the user agent that sends requests and receives responses. to increase the speed of processing. UAS and UAC are logical entities only.com. registrars. In this case the callee’s user agent (sending BYE) behaves like UAC and the caller’s user agent behaves like UAS. such URIs are easy to remember. we often say that a user agent behaves like a UAC or UAS. sip:joe@company. Note that the elements.3. it is. User Agents Internet end points that use SIP to find each other and to negotiate a session characteristics are called user agents. possible to use the same URI for e-mail and SIP communication.1. We will briefly describe them in this section. as presented in this section. caller’s user agent behaves like UAC when it sends an INVITE requests and receives responses to the request. But this situation changes when the callee decides to send a BYE and terminate the session. a typical SIP network will contain more than one type of SIP elements. It is often profitable to co-locate them together. SIP Introduction 1.2. PSTN gateways. for instance.Chapter 1. reside on a user’s computer in form of an application--this is currently the most widely used approach. SIP Network Elements Although in the simplest configuration it is possible to use just two user agents that send SIP messages directly to each other. 2 . proxies. and redirect servers. for instance. A SIP URI has form of sip:username@domain. Because a user agent contains both UAC and UAS. each user agent contains a UAC and UAS. For instance. for instance. 1. As we can see. PDAs.3. but that depends on a particular implementation and configuration. automated IVR systems and so on. Callee’s user agent behaves like a UAS when it receives the INVITE and sends responses.

There are two basic types of SIP proxy servers--stateless and stateful. In our example callee B picked up and later when he wants to tear down the call it sends a BYE. 1. SIP Introduction Figure 1-1. each of them is responsible for one branch. Proxy Servers In addition to that SIP allows creation of an infrastructure of network hosts called proxy servers. UAC and UAS Figure 1-1 shows three user agents and one stateful forking proxy.Chapter 1. accounting and many other important functions. At this time the user agent that was previously UAS becomes a UAC and vice versa. 3 . The most important task of a proxy server is to route session invitations “closer” to callee. When forwarding the request statefully the proxy creates two UACs. Such a proxy will forward the session invitation directly to the callee and the callee will then accept or decline the session invitation. Proxy servers are very important entities in the SIP infrastructure. Each user agent contains UAC and UAS. The session invitation will usually traverse a set of proxies until it finds one which knows the actual location of the callee. User agents can send messages to a proxy server.3. The part of the proxy that receives the INVITE from the caller in fact acts as a UAS. They perform routing of a session invitations according to invitee’s current location. authentication.2.

It is. especially those created by INVITE.3. They often perform accounting. Although messages are usually arranged into transactions (see Section 1. Stateful proxies can perform forking. Figure 1-2 shows how a session invitation from employee Joe in company A will reach employee Bob in company B. their performance is limited. Stateless Servers Stateless server are simple message forwarders. They can be used as simple load balancers. Stateful proxies can absorb retransmissions because they know. stateful proxies create a state and keep the state until the transaction finishes.1. forking or recursive traversal. if they have already received the same message (stateless proxies cannot do the check because they keep no state).2. Some transactions. forking. They forward messages independently of each other. 4 . Because stateful proxies must maintain the state for the duration of the transactions. for instance.2. some sort of NAT traversal aid and all those features require a stateful proxy. SIP Introduction 1. Stateless proxies can’t do this because they have no way of knowing how the transaction targeted to the office phone finished.2.3. that means upon reception of a message two or more messages will be sent out.3. 1. stateless proxies do not take care of transactions.2. can last quite long (until callee picks up or declines the call). Let’s suppose that there are two companies A and B and each of them has it’s own proxy server. Stateless proxies are simple. message translators and routers. for instance) has it’s own SIP proxy server which is used by all user agents in the entity. 1.3. One of drawbacks of stateless proxies is that they are unable to absorb retransmissions of messages and perform more advanced routing. Proxy Server Usage A typical configuration is that each centrally administered entity (a company. but faster than stateful proxy servers.Chapter 1. possible to try to reach user’s office phone and when he doesn’t pick up then the call is redirected to his cell phone. Stateful Servers Stateful proxies are more complex. for instance. Most SIP proxies today are stateful because their configuration is usually very complex. Upon reception of a request. The ability to associate SIP messages into transactions gives stateful proxies some interesting features. Stateful proxies can perform more complicated methods of finding a user.5). from the transaction state.

b. The proxy server figures out that user sip:bob@b. When the proxy receives an invitation for sip:bob@b.org and contact address sip:jan@1. The registrar is a special SIP entity that receives registrations from users. Because of their tight coupling with proxies registrars. 1. Session Invitation User Joe uses address sip:bob@b.2.3. Purpose of the location database is to map sip:bob@b. port and username in this case) and stores the information into location database. is sent to the registrar.a.2.2. Joe’s user agent doesn’t know how to route the invitation itself but it is configured to send all outbound traffic to the company SIP proxy server proxy.com. The location database is then used by B’s proxy server. The invitation reaches proxy.4:5060 where 1.3. are usually co-located with proxy servers. Registrar We mentioned that the SIP proxy at proxy.a.bo. A registrar is very often a logical entity only. A REGISTER message containing Address of Record sip:jan@iptel. The proxy knows that Bob is currently sitting in his office and is reachable through phone on his desk. extracts information about their current location (IP address. It finds sip:bob@1.com to call Bob.4:5060 and will send the invitation there.3.com knows current Bob’s location but haven’t mentioned yet how a proxy can learn current location of a user.4. Figure 1-3 shows a typical SIP registration.com or the proxy will use DNS SRV records to find B’s proxy server.3.com it will search the location database.2.4:5060. If everything went well then the registrar sends a 200 OK response to the phone and the process of registration is finished.com.com is in a different company so it will look up B’s SIP proxy server and send the invitation there.4 is IP address of the phone.3. Bob’s user agent (SIP phone) must register with a registrar. 5 . so the proxy will send the invitation there.3. SIP Introduction Figure 1-2.com to something like sip:bob@1. The registrar extracts this information and stores it into the location database. which has IP address 1.2. B’s proxy server can be either preconfigured at proxy.3.Chapter 1.

Registrar Overview Each registration has a limited lifespan. Figure 1-4 shows a typical redirection. The originator of the request then extracts the list of destinations and sends another request directly to them. Redirect Server The entity that receives a request and sends back a reply containing a list of the current location of a particular user is called redirect server.Chapter 1. SIP Introduction Figure 1-3. The user agent must refresh the registration within the lifespan otherwise it will expire and the user will become unavailable. It then creates a list of current locations of the user and sends it to the request originator in a response within 3xx class. 6 . 1.4.3. Expires header field or expires parameter of Contact header field determines for how long is the registration valid. A redirect server receives requests and looks up the intended recipient of the request in the location database created by a registrar.

and message body.20. SIP Redirection 1.128.org> Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.4. Usually they are transported in a separate UDP datagram each. Requests are usually used to initiate some action or inform recipient of the request of something. SIP Introduction Figure 1-4.35:9315> User-Agent: Windows RTC/1.35 s=session c=IN IP4 213.iptel. nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c". uri="sip:jiri@bat. There are two types of messages--requests and responses. message header. Messages can be transported independently by the network. realm="iptel. Each message consist of “first line”.0/UDP 195.org SIP/2.37.128.128.org".0 Proxy-Authorization: Digest username="jiri".org".77. The first line identifies type of the message.128.35 b=CT:1000 7 .iptel.20.Chapter 1.100:5040.0 Via: SIP/2.20. A typical SIP request looks like this: INVITE sip:7170@iptel.tag=76ff7a07-c091-4192-84a0-d56e91fe104f To: <sip:jiri@bat. algorithm="MD5".org>. response="53fe98db10e1074 b03b3e06438bda70f" Content-Type: application/sdp Content-Length: 451 v=0 o=jku2 0 0 IN IP4 213.35 CSeq: 2 INVITE Contact: <sip:213. Replies are used to confirm that a request was received and processed and contain the status of the processing.rport Max-Forwards: 10 From: "jiri" <sip:jiri@iptel. SIP Messages Communication using SIP (often called signalling) comprises of series of messages.20.

CSeq is used to maintain order of requests. Contact header field contains IP aaddress and port on which the sender is awaiting further requests sent by callee. From the Via field we can tell that the user agent is running on host 195. a sequence number must be present in the messages so that recipient can identify retransmissions and out of order requests. Because requests can be sent over an unreliable transport that can re-order messages.6. Call-ID header field is a dialog identifier and it’s purpose is to identify messages belonging to the same call.org is called Request URI and contains URI of the next hop of the message.1. The INVITE message contains just one Via header field which was created by the user agent that sent the request. Message header is delimited from message body by an empty line. Establishing of a session utilizes 3-way hand-shaking due to asymmetric nature of the invitation. A SIP request can contain one or more Via header fields which are used to record path of the request. Such messages have the same Call-ID identifier.org. 1. SIP Introduction t=0 0 m=audio 54742 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap: 3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 The first line tells us that this is INVITE message which is used to establish a session. From header field contains a tag parameter which serves as a dialog identifier and will be described in Section 1. Other header fields are not important and will be not described here. 8 . It may take a while before the callee accepts or declines the call so the callee’s user agent periodically retransmits a positive final response until it receives an ACK (which indicates that the caller is still there and ready to communicate). They are later used to route SIP responses exactly the same way.Chapter 1. In this case it will be host iptel. SIP Requests We have described how an INVITE request looks like and said that the request is used to invite a callee to a session.100 and port 5060.4.37. From and To header fields identify initiator (caller) and recipient (callee) of the invitation (just like in SMTP where they identify sender and recipient of a message).77. Other important requests are: • ACK--This message acknowledges receipt of a final response to INVITE. Message body of the INVITE request contains a description of the media type accepted by the sender and encoded in SDP. The URI on the first line--sip:7170@iptel.

2.77.168. Registrar extracts this information and puts it into a location database. The reply code is an integer number from 100 to 699 and indicates type of the response.8. • CANCEL--Cancel is used to cancel not yet fully established session.68 req_src_port=5060 in_uri=sip:iptel.expires=120 Server: Sip EXpress router (0.org out_uri=sip:iptel. 1.org.48. A typical reply looks like this: SIP/2.1.0). There are 6 classes of responses: • 1xx are provisional responses. The first line of response contains protocol version (SIP/2.org via_cnt==1" As we can see. • REGISTER--Purpose of REGISTER request is to let registrar know of current user’s location.87. A provisional response is response that tells to its recipient that the associated request was received but result of the processing is not known yet.received=66.4. SIP Introduction • BYE--Bye messages are used to tear down multimedia sessions. A party wishing to tear down a session sends a BYE to the other party.68:5060. Information about current IP address and port on which a user can be reached is carried in REGISTER messages. It is used when the callee hasn’t replied with a final response yet but the caller wants to abort the call (typically when a callee doesn’t respond for some time). The database can be later used by SIP proxy servers to route calls to the user. SIP Responses When a user agent or proxy server receives a request it send a reply.transport=udp>.101:5060 "Noisy feedback tells: pid=5110 req_src_ip=66. The sender must stop retransmitting the request upon reception of a provisional response.0/UDP 192.0 200 OK Via: SIP/2. Provisional responses are sent only when the processing doesn’t finish immediately.48.00.87. responses are very similar to the requests. Each request must be replied except ACK requests which trigger no replies.11pre21xrc (i386/linux)) Content-Length: 0 Warning: 392 195. Typically proxy servers send responses with code 100 when they start processing an INVITE and user agents send responses with code 180 (Ringing) which means that the callee’s phone is ringing. 9 . except for the first line.30:5060. Registrations are time-limited and need to be periodically refreshed. The listed requests usually have no message body because it is not needed in most situations (but can have one). reply code. In addition to that many other request types have been defined but their description is out of the scope of this document.168.30 CSeq: 63629 REGISTER Contact: <sip:sip2@66.68 From: sip:sip2@iptel.87.b713 Call-ID: 2443936363@192.org To: sip:sip2@iptel.37.q=0.Chapter 1.tag=794fe65c16edfdf45da4fc39a5d2867c.48.1. and reason phrase.

SIP Transactions Although we said that SIP messages are sent independently over the network. That includes zero or more provisional responses and one or more final responses (remember that an INVITE might be answered by more than one final response when a proxy server forks the request). In addition to the response class the first line also contains reason phrase. The request to which a particular response belongs is identified using the CSeq header field. The request couldn’t be processed because it contains bad syntax or cannot be fulfilled at that server. When a proxy receives a request and doesn’t want or can’t process it for any reason. In this case each response is distinguished by the tag parameter in To header field. A transaction is a sequence of SIP messages exchanged between SIP network elements. User agents usually send a 603 Decline response when the user doesn’t want to participate in the session. a 4xx response means that the problem is on the sender’s side. A final response is the ultimate response that the originator of the request will ever receive. • 6xx reply code means that the request cannot be fulfilled at any server. It is not very human-friendly but it is very easy to parse and understand by machines.5. Therefore final responses express result of the processing of the associated request. Responses with code from 200 to 299 are positive responses that means that the request was processed successfully and accepted. This is because a forking proxy (described later) can fork the request so it will reach several UAS and each of them will accept the invitation. • 3xx responses are used to redirect a caller. A user agent should render the reason phrase to the user. The code number is intended to be processed by machines. In addition to the sequence number this header field also contains method of corresponding request. Each response represents a distinct dialog with unambiguous dialog identifier. A redirection response gives information about the user’s new location or an alternative service that the caller might use to satisfy the call. The request is apparently valid but the server failed to fulfill it. 10 . • 5xx means that the problem is on server’s side. Final responses also terminate transactions. Clients should usually retry the request later. The reason phrase usually contains a human-readable message describing the result of the processing. A UAC may receive several 200 messages to a single INVITE request. it will send a redirection response to the caller and put another location into the response which the caller might want to try. The caller is then supposed to re-send the request to the new location. 1. 3xx responses are final. SIP Introduction • 2xx responses are positive final responses. Therefore SIP is said to be a transactional protocol. • 4xx are negative final responses.Chapter 1. This response is usually sent by a server that has definitive information about a particular user. A transaction consists of one request and all responses to that request. they are usually arranged into transactions by user agents and certain types of proxy servers. In our example it was REGISTER request. For instance a 200 OK response is sent when a user accepts invitation to a session (INVITE request). Redirection responses are usually sent by proxy servers. It can be the location of another proxy or the current location of the callee (from the location database created by a registrar).

When a request or response comes.ietf. Figure 1-5.Chapter 1. They must be backwards compatible. Branch parameter of Via header fields contains directly the transaction identifier. SIP Introduction If a transaction was initiated by an INVITE request then the same transaction also includes ACK.txt) the way of calculating transaction identifiers was completely changed. Such entities usually create a state associated with a transaction that is kept in the memory for the duration of the transaction. The reason for this separation is the importance of delivery of all 200 OK messages. but only if the final response was not a 2xx response. but there still exist old implementations that don’t support the new way of calculating of transaction identifier so even new implementations have to support the old way. This is significant simplification. As we can see this is quite asymmetric behavior--ACK is part of transactions with a negative final response but is not part of transactions with positive final responses. Not only that they establish a session. In the previous SIP RFC2543 (http://www. SIP Transactions 11 .org/rfc/rfc3261. If such a transaction exists then it’s state gets updated from the message. Also note that only responses to INVITE are retransmitted ! SIP entities that have notion of transactions are called stateful. In the new RFC3261 (http://www. a stateful entity tries to associate the request (or response) to existing transactions. Request-URI and CSeq). If the final response was a 2xx response then the ACK is not considered part of the transaction. From. Instead of complicated hashing of important header fields a SIP message now includes the identifier directly. Figure 1-5 shows what messages belong to what transactions during a conversation of two user agents.txt) the transaction identifier was calculated as hash of all important message header fields (that included To. Therefore user agents take responsibility in this case and retransmit 200 OK responses until they receive an ACK. but also 200 OK can be generated by multiple entities when a proxy server forks the request and all of them must be delivered to the calling user agent. To be able to do it it must extract a unique transaction identifier from the message and compare it to identifiers of all existing transactions. This proved to be very slow and complex.ietf. during interoperability tests such transaction identifiers used to be a common source of problems.org/rfc/rfc2543.

A dialog represents a peer-to-peer SIP relationship between two user agents. This BYE is sent within the dialog established by the INVITE. This allows to explicitly express the relationship of messages and also to send messages that are not related to other messages outside a dialog. But we feel that those two transactions should be somehow related--both of them belong to the same dialog. A dialog persists for some time and it is very important concept for user agents. Messages that have these three identifiers same belong to the same dialog. Dialogs facilitate proper sequencing and routing of messages between SIP endpoints. Dialogs are identified using Call-ID.Chapter 1. 12 . In fact. Figure 1-6. INVITE message establishes a dialog. The number must be monotonically increased for each message sent within a dialog otherwise the peer will handle it as out of order request or retransmission. One could also say that a dialog is a sequence of transactions. SIP Dialog Some messages establish a dialog and some do not. We have shown that CSeq header field is used to order messages. That is easier to implement because user agent don’t have to keep the dialog state. Figure 1-6 extends Figure 1-5 to show which messages belong to the same dialog. For instance. This means that only one transaction in each direction can be active within a dialog. From tag. in fact it is used to order messages within a dialog. and To tag.6. that one transaction includes INVITE and it’s responses and another transaction includes BYE and it responses when a session is being torn down. SIP Introduction 1. because it will be later followed by BYE request which will tear down the session established by the INVITE. the CSeq number identifies a transaction within a dialog because we have said that requests and associated responses are called transaction. SIP Dialogs We have shown what transactions are.

SIP Trapezoid 13 . The request will be sent from proxy to proxy until it reaches one that knows current location of the callee. they are used to route just the first request that establishes the dialog. Therefore the INVITE request will be sent to a proxy server.1. Any subsequent messages (even MESSAGE) will be sent independently of the previous one. This process is called routing. 1. The direct messages are also delivered with much smaller latency because a typical proxy usually implements complex routing logic. The original request also contained Contact header field which means that both user agents know the current location of the peer. Figure 1-7 contains an example of a message within a dialog (BYE) that bypasses the proxies. That’s exactly how dialogs facilitate routing. Once the request reaches the callee. the callee’s user agent will create a response that will be sent back to the caller. such a request doesn’t establish any dialog. Let’s suppose that user sip:bob@a. Callee’s user agent will also put Contact header field into the response which will contain the current location of the user. the caller doesn’t know to which host to send the request.com wants to talk to user sip:pete@b. This is a significant performance improvement because proxies do not see all the messages within a dialog. Because the user agents know location of each other.com.6. Dialogs Facilitate Routing We have said that dialogs are also used to route the messages between user agents. Figure 1-7. SIP Introduction But if a user agent sends a MESSAGE request. He knows SIP address of the callee (sip:pete@b.Chapter 1.com) but this address doesn’t say anything about current location of the user--i.e. it is not necessary to send further requests to any proxy--they can be sent directly from user agent to user agent. let’s describe this a little bit. Further messages within a dialog are sent directly from user agent to user agent.

To tag is generated by a callee and it uniquely identifies. Figure 1-8 shows an example of registration.2. the dialog in the callee’s user agent. 1. Call-ID is so called call identifier. It must be a unique string that identifies a call. A registration comprises a REGISTER message followed by a 200 OK sent by registrar if the registration was successful. 1. From tag.7.Chapter 1. and To tag. SIP Introduction 1. Multiple user agents may respond to a request when a proxy along the path forks the request. A call consists of one or more dialogs. just like From tag. Registrations are usually authorized so a 407 reply can appear if the user didn’t provide valid credentials. REGISTER Message Flow 14 . Dialog Identifiers We have already shown that dialog identifiers consist of three parts. This hierarchical dialog identifier is necessary because a single call invitation can create several dialogs and caller must be able to distinguish them. but it is not that clear why are dialog identifiers created exactly this way and who contributes which part. Each user agent that sends a 2xx establishes a separate dialog with the caller. From tag is generated by the caller and it uniquely identifies the dialog in the caller’s user agent. Figure 1-8.1. Typical SIP Scenarios This section gives a brief overview of typical SIP scenarios that usually make up the SIP traffic.7.6. All such dialogs are part of the same call and have the same Call-ID. Registration Users must register themselves with a registrar to be reachable by other users. Call-Id.

Chapter 1. See Figure 1-10. SIP Introduction 1. The response is generated when callee’s phone starts ringing.4.7. INVITE Message Flow A 200 OK is generated once the callee picks up the phone and it is retransmitted by the callee’s user agent until it receives an ACK from the caller. Session Invitation A session invitation consists of one INVITE request which is usually sent to a proxy. See 180 Ringing response in the call flow. The session is established at this point. The proxy sends immediately a 100 Trying reply to stop retransmissions and forwards the request further. Session Termination Session termination is accomplished by sending a BYE request within dialog established bye INVITE.3. All provisional responses generated by callee are sent back to the caller. Party wishing to tear down a session sends a BYE request to the other party involved in the session. BYE messages are sent directly from one user agent to the other unless a proxy on the path of the INVITE request indicated that it wishes to stay on the path by using record routing (see Section 1.7. 1. 15 . The other party sends a 200 OK response to confirm the BYE and the session is terminated.2. left message flow.7. Figure 1-9.

This approach makes SIP network more scalable because only a small number of SIP messages hit the proxies.7. Messages sent within a dialog will then traverse all SIP proxies that put a Record-Route header field into the message. Event Subscription And Notification The SIP specification has been extended to support a general mechanism allowing subscription to asynchronous events. Right message flow show how the situation changes when the proxy puts a Record-Route header field into the message. 1. session changes and so on.4. Such evens can include SIP proxy statistics changes. There are certain situations in which a SIP proxy need to stay on the path of all further messages. Record Routing All requests sent within a dialog are by default sent directly from one user agent to the other. For instance.Chapter 1. The recipient of the request receives a set of Record-Route header fields in the message. It must mirror all the Record-Route header fields into responses because the originator of the request also needs to know the set of proxies.7. proxies controlling a NAT box or proxies doing accounting need to stay on the path of BYE requests. Figure 1-10. 16 .5. SIP Introduction 1. The mechanism is used mainly to convey information on presence (willingness to communicate) of users. Only requests outside a dialog traverse SIP proxies. Mechanism by which a proxy can inform user agents that it wishes to stay on the path of all further messages is called record routing. presence information. Such a proxy would insert Record-Route header field into SIP messages which contain address of the proxy. Figure 1-11 shows the basic message flow. BYE Message Flow (With and without Record Routing) Left message flow of Figure 1-10 show how a BYE (request within dialog established by INVITE) is sent directly to the other user agent when there is no Record-Route header field in the message.

The SUBSCRIBE message establishes a dialog and is immediately replied by the server using 200 OK response. Subscriptions--as well as registrations--have limited lifespan and therefore must be periodically refreshed. NOTIFY messages are sent within the dialog established by the SUBSCRIBE. Figure 1-12. 1. Event Subscription And Notification A user agent interested in event notification sends a SUBSCRIBE message to a SIP server. Instant Messages Instant messages are sent using MESSAGE request. The text of the instant message is transported in the body of the SIP request. SIP Introduction Figure 1-11.Chapter 1. This is the simplest form of sending instant messages. MESSAGE requests do not establish a dialog and therefore they will always traverse the same set of proxies.6. Instant Messages 17 . Note that the first NOTIFY message in Figure 1-11 is sent regardless of any event that triggers notifications. At this point the dialog is established.7. The server sends a NOTIFY request to the user every time the event to which the user subscribed changes.

SIP Introduction 18 .Chapter 1.