Sip route header

Sip route header DEFAULT

1. SIP Introduction

Copyright © 2003 FhG FOKUS

Abstract

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


SIP stands for Session Initiation Protocol. It is an application-layer control protocol which has been developed and designed within the IETF. The protocol has been designed with easy implementation, good scalability, and flexibility in mind.

The specification is available in form of several RFCs, the most important one is RFC3261 which contains the core protocol specification. The protocol is used for creating, modifying, and terminating sessions with one or more participants. By sessions we understand a set of senders and receivers that communicate and the state kept in those senders and receivers during the communication. Examples of a session can include Internet telephone calls, distribution of multimedia, multimedia conferences, distributed computer games, etc.

SIP is not the only protocol that the communicating devices will need. It is not meant to be a general purpose protocol. Purpose of SIP is just to make the communication possible, the communication itself must be achieved by another means (and possibly another protocol). Two protocols that are most often used along with SIP are RTP and SDP. RTP protocol is used to carry the real-time multimedia data (including audio, video, and text), the protocol makes it possible to encode and split the data into packets and transport such packets over the Internet. Another important protocol is SDP, which is used to describe and encode capabilities of session participants. Such a description is then used to negotiate the characteristics of the session so that all the devices can participate (that includes, for example, negotiation of codecs used to encode media so all the participants will be able to decode it, negotiation of transport protocol used and so on).

SIP has been designed in conformance with the Internet model. It is an end-to-end oriented signaling protocol which means, that all the logic is stored in end devices (except routing of SIP messages). State is also stored in end-devices only, there is no single point of failure and networks designed this way scale well. The price that we have to pay for the distributiveness and scalability is higher message overhead, caused by the messages being sent end-to-end.

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. Aim of SIP is to provide the same functionality that the traditional PSTNs have, 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.

SIP is based on HTTP protocol. The HTTP protocol inherited format of message headers from RFC822. HTTP is probably the most successful and widely used protocol in the Internet. It tries to combine the best of the both. In fact, HTTP can be classified as a signaling protocol too, because user agents use the protocol to tell a HTTP server in which documents they are interested in. SIP is used to carry the description of session parameters, the description is encoded into a document using SDP. Both protocols (HTTP and SIP) have inherited encoding of message headers from RFC822. The encoding has proven to be robust and flexible over the years.

SIP entities are identified using SIP URI (Uniform Resource Identifier). A SIP URI has form of sip:[email protected], for instance, sip:[email protected] As we can see, SIP URI consists of username part and domain name part delimited by @ (at) character. SIP URIs are similar to e-mail addresses, it is, for instance, possible to use the same URI for e-mail and SIP communication, such URIs are easy to remember.

1.3. 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, a typical SIP network will contain more than one type of SIP elements. Basic SIP elements are user agents, proxies, registrars, and redirect servers. We will briefly describe them in this section.

Note that the elements, as presented in this section, are often only logical entities. It is often profitable to co-locate them together, for instance, to increase the speed of processing, but that depends on a particular implementation and configuration.

Internet end points that use SIP to find each other and to negotiate a session characteristics are called user agents. User agents usually, but not necessarily, reside on a user's computer in form of an application--this is currently the most widely used approach, but user agents can be also cellular phones, PSTN gateways, , automated systems and so on.

User agents are often referred to as User Agent Server (UAS) and User Agent Client (UAC). UAS and UAC are logical entities only, each user agent contains a UAC and UAS. UAC is the part of the user agent that sends requests and receives responses. UAS is the part of the user agent that receives requests and sends responses.

Because a user agent contains both UAC and UAS, we often say that a user agent behaves like a UAC or UAS. For instance, caller's user agent behaves like UAC when it sends an INVITE requests and receives responses to the request. Callee's user agent behaves like a UAS when it receives the INVITE and sends responses.

But this situation changes when the callee decides to send a BYE and terminate the session. In this case the callee's user agent (sending BYE) behaves like UAC and the caller's user agent behaves like UAS.

Figure 1. UAC and UAS


Figure 1, “UAC and UAS” shows three user agents and one stateful forking proxy. Each user agent contains UAC and UAS. The part of the proxy that receives the INVITE from the caller in fact acts as a UAS. When forwarding the request statefully the proxy creates two UACs, each of them is responsible for one branch.

In our example callee B picked up and later when he wants to tear down the call it sends a BYE. At this time the user agent that was previously UAS becomes a UAC and vice versa.

In addition to that SIP allows creation of an infrastructure of network hosts called proxy servers. User agents can send messages to a proxy server. Proxy servers are very important entities in the SIP infrastructure. They perform routing of a session invitations according to invitee's current location, authentication, accounting and many other important functions.

The most important task of a proxy server is to route session invitations "closer" to callee. The session invitation will usually traverse a set of proxies until it finds one which knows the actual location of the callee. Such a proxy will forward the session invitation directly to the callee and the callee will then accept or decline the session invitation.

There are two basic types of SIP proxy servers--stateless and stateful.

1.3.2.1. Stateless Servers

Stateless server are simple message forwarders. They forward messages independently of each other. Although messages are usually arranged into transactions (see Section 1.5, “SIP Transactions”), stateless proxies do not take care of transactions.

Stateless proxies are simple, but faster than stateful proxy servers. They can be used as simple load balancers, message translators and routers. One of drawbacks of stateless proxies is that they are unable to absorb retransmissions of messages and perform more advanced routing, for instance, forking or recursive traversal.

1.3.2.2. Stateful Servers

Stateful proxies are more complex. Upon reception of a request, stateful proxies create a state and keep the state until the transaction finishes. Some transactions, especially those created by INVITE, can last quite long (until callee picks up or declines the call). Because stateful proxies must maintain the state for the duration of the transactions, their performance is limited.

The ability to associate SIP messages into transactions gives stateful proxies some interesting features. Stateful proxies can perform forking, that means upon reception of a message two or more messages will be sent out.

Stateful proxies can absorb retransmissions because they know, from the transaction state, if they have already received the same message (stateless proxies cannot do the check because they keep no state).

Stateful proxies can perform more complicated methods of finding a user. It is, for instance, 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. Stateless proxies can't do this because they have no way of knowing how the transaction targeted to the office phone finished.

Most SIP proxies today are stateful because their configuration is usually very complex. They often perform accounting, forking, some sort of NAT traversal aid and all those features require a stateful proxy.

1.3.2.3. Proxy Server Usage

A typical configuration is that each centrally administered entity (a company, for instance) has it's own SIP proxy server which is used by all user agents in the entity. Let's suppose that there are two companies A and B and each of them has it's own proxy server. Figure 2, “Session Invitation” shows how a session invitation from employee Joe in company A will reach employee Bob in company B.

Figure 2. Session Invitation


User Joe uses address sip:[email protected] to call Bob. 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.a.com. The proxy server figures out that user sip:[email protected] is in a different company so it will look up B's SIP proxy server and send the invitation there. B's proxy server can be either pre-configured at proxy.a.com or the proxy will use records to find B's proxy server. The invitation reaches proxy.bo.com. The proxy knows that Bob is currently sitting in his office and is reachable through phone on his desk, which has IP address 1.2.3.4, so the proxy will send the invitation there.

We mentioned that the SIP proxy at proxy.b.com knows current Bob's location but haven't mentioned yet how a proxy can learn current location of a user. Bob's user agent (SIP phone) must register with a registrar. The registrar is a special SIP entity that receives registrations from users, extracts information about their current location (IP address, port and username in this case) and stores the information into location database. Purpose of the location database is to map sip:[email protected] to something like sip:[email protected]:5060. The location database is then used by B's proxy server. When the proxy receives an invitation for sip:[email protected] it will search the location database. It finds sip:[email protected]:5060 and will send the invitation there. A registrar is very often a logical entity only. Because of their tight coupling with proxies registrars, are usually co-located with proxy servers.

Figure 3, “Registrar Overview” shows a typical SIP registration. A REGISTER message containing Address of Record sip:[email protected] and contact address sip:[email protected]:5060 where 1.2.3.4 is IP address of the phone, is sent to the registrar. The registrar extracts this information and stores it into the location database. If everything went well then the registrar sends a 200 OK response to the phone and the process of registration is finished.

Figure 3. Registrar Overview


Each registration has a limited lifespan. Expires header field or expires parameter of Contact header field determines for how long is the registration valid. The user agent must refresh the registration within the lifespan otherwise it will expire and the user will become unavailable.

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. A redirect server receives requests and looks up the intended recipient of the request in the location database created by a registrar. It then creates a list of current locations of the user and sends it to the request originator in a response within 3xx class.

The originator of the request then extracts the list of destinations and sends another request directly to them. Figure 4, “SIP Redirection” shows a typical redirection.

Figure 4. SIP Redirection


Communication using SIP (often called signaling) comprises of series of messages. Messages can be transported independently by the network. Usually they are transported in a separate UDP datagram each. Each message consist of "first line", message header, and message body. The first line identifies type of the message. There are two types of messages--requests and responses. Requests are usually used to initiate some action or inform recipient of the request of something. Replies are used to confirm that a request was received and processed and contain the status of the processing.

A typical SIP request looks like this:

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 195.37.77.100:5040;rport Max-Forwards: 10 From: "jiri" <sip:[email protected]>;tag=76ff7a07-c091-4192-84a0-d56e91fe104f To: <sip:[email protected]> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:213.20.128.35:9315> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="jiri", realm="iptel.org", algorithm="MD5", uri="sip:[email protected]", nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c", response="53fe98db10e1074 b03b3e06438bda70f" Content-Type: application/sdp Content-Length: 451 v=0 o=jku2 0 0 IN IP4 213.20.128.35 s=session c=IN IP4 213.20.128.35 b=CT:1000 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. The URI on the first line--sip:[email protected] is called Request URI and contains URI of the next hop of the message. In this case it will be host iptel.org.

A SIP request can contain one or more Via header fields which are used to record path of the request. They are later used to route SIP responses exactly the same way. The INVITE message contains just one Via header field which was created by the user agent that sent the request. From the Via field we can tell that the user agent is running on host 195.37.77.100 and port 5060.

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). From header field contains a tag parameter which serves as a dialog identifier and will be described in Section 1.6, “SIP Dialogs”.

Call-ID header field is a dialog identifier and it's purpose is to identify messages belonging to the same call. Such messages have the same Call-ID identifier. CSeq is used to maintain order of requests. Because requests can be sent over an unreliable transport that can re-order messages, a sequence number must be present in the messages so that recipient can identify retransmissions and out of order requests.

Contact header field contains IP address and port on which the sender is awaiting further requests sent by callee. Other header fields are not important and will be not described here.

Message header is delimited from message body by an empty line. Message body of the INVITE request contains a description of the media type accepted by the sender and encoded in SDP.

We have described how an INVITE request looks like and said that the request is used to invite a callee to a session. Other important requests are:

  • ACK--This message acknowledges receipt of a final response to INVITE. Establishing of a session utilizes 3-way hand-shaking due to asymmetric nature of the invitation. 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).
  • 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.
  • CANCEL--Cancel is used to cancel not yet fully established session. 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).
  • REGISTER--Purpose of REGISTER request is to let registrar know of current user's location. Information about current IP address and port on which a user can be reached is carried in REGISTER messages. Registrar extracts this information and puts it into a location database. The database can be later used by SIP proxy servers to route calls to the user. 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). In addition to that many other request types have been defined but their description is out of the scope of this document.

When a user agent or proxy server receives a request it send a reply. Each request must be replied except ACK requests which trigger no replies.

A typical reply looks like this:

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68 From: sip:[email protected] To: sip:[email protected];tag=794fe65c16edfdf45da4fc39a5d2867c.b713 Call-ID: [email protected] CSeq: 63629 REGISTER Contact: Msip:[email protected]:5060;transport=udp>;q=0.00;expires=120 Server: Sip EXpress router (0.8.11pre21xrc (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org out_uri=sip:iptel.org via_cnt==1"

As we can see, responses are very similar to the requests, except for the first line. The first line of response contains protocol version (SIP/2.0), reply code, and reason phrase.

The reply code is an integer number from 100 to 699 and indicates type of the response. There are 6 classes of responses:

  • 1xx are provisional responses. A provisional response is response that tells to its recipient that the associated request was received but result of the processing is not known yet. Provisional responses are sent only when the processing doesn't finish immediately. The sender must stop retransmitting the request upon reception of a provisional response.

    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.

  • 2xx responses are positive final responses. A final response is the ultimate response that the originator of the request will ever receive. Therefore final responses express result of the processing of the associated request. Final responses also terminate transactions. Responses with code from 200 to 299 are positive responses that means that the request was processed successfully and accepted. For instance a 200 OK response is sent when a user accepts invitation to a session (INVITE request).

    A UAC may receive several 200 messages to a single INVITE request. This is because a forking proxy (described later) can fork the request so it will reach several UAS and each of them will accept the invitation. In this case each response is distinguished by the tag parameter in To header field. Each response represents a distinct dialog with unambiguous dialog identifier.

  • 3xx responses are used to redirect a caller. A redirection response gives information about the user's new location or an alternative service that the caller might use to satisfy the call. Redirection responses are usually sent by proxy servers. When a proxy receives a request and doesn't want or can't process it for any reason, it will send a redirection response to the caller and put another location into the response which the caller might want to try. It can be the location of another proxy or the current location of the callee (from the location database created by a registrar). The caller is then supposed to re-send the request to the new location. 3xx responses are final.
  • 4xx are negative final responses. a 4xx response means that the problem is on the sender's side. The request couldn't be processed because it contains bad syntax or cannot be fulfilled at that server.
  • 5xx means that the problem is on server's side. The request is apparently valid but the server failed to fulfill it. Clients should usually retry the request later.
  • 6xx reply code means that the request cannot be fulfilled at any server. This response is usually sent by a server that has definitive information about a particular user. User agents usually send a 603 Decline response when the user doesn't want to participate in the session.

In addition to the response class the first line also contains reason phrase. The code number is intended to be processed by machines. It is not very human-friendly but it is very easy to parse and understand by machines. The reason phrase usually contains a human-readable message describing the result of the processing. A user agent should render the reason phrase to the user.

The request to which a particular response belongs is identified using the CSeq header field. In addition to the sequence number this header field also contains method of corresponding request. In our example it was REGISTER request.

Although we said that SIP messages are sent independently over the network, they are usually arranged into transactions by user agents and certain types of proxy servers. Therefore SIP is said to be a transactional protocol.

A transaction is a sequence of SIP messages exchanged between SIP network elements. A transaction consists of one request and all responses to that request. That includes zero or more provisional responses and one or more final responses (remember that an INVITE might be answered by more than one final response when a proxy server forks the request).

If a transaction was initiated by an INVITE request then the same transaction also includes ACK, but only if the final response was not a 2xx response. If the final response was a 2xx response then the ACK is not considered part of the transaction.

As we can see this is quite asymmetric behavior--ACK is part of transactions with a negative final response but is not part of transactions with positive final responses. The reason for this separation is the importance of delivery of all 200 OK messages. Not only that they establish a session, but also 200 OK can be generated by multiple entities when a proxy server forks the request and all of them must be delivered to the calling user agent. Therefore user agents take responsibility in this case and retransmit 200 OK responses until they receive an ACK. Also note that only responses to INVITE are retransmitted !

SIP entities that have notion of transactions are called stateful. Such entities usually create a state associated with a transaction that is kept in the memory for the duration of the transaction. When a request or response comes, a stateful entity tries to associate the request (or response) to existing transactions. To be able to do it it must extract a unique transaction identifier from the message and compare it to identifiers of all existing transactions. If such a transaction exists then it's state gets updated from the message.

In the previous SIP RFC2543 the transaction identifier was calculated as hash of all important message header fields (that included To, From, Request-URI and CSeq). This proved to be very slow and complex, during interoperability tests such transaction identifiers used to be a common source of problems.

In the new RFC3261 the way of calculating transaction identifiers was completely changed. Instead of complicated hashing of important header fields a SIP message now includes the identifier directly. Branch parameter of Via header fields contains directly the transaction identifier. This is significant simplification, but there still exist old implementations that don't support the new way of calculating of transaction identifier so even new implementations have to support the old way. They must be backwards compatible.

Figure 5, “SIP Transactions” shows what messages belong to what transactions during a conversation of two user agents.

Figure 5. SIP Transactions


We have shown what transactions are, that one transaction includes INVITE and it's responses and another transaction includes BYE and it responses when a session is being torn down. But we feel that those two transactions should be somehow related--both of them belong to the same dialog. A dialog represents a peer-to-peer SIP relationship between two user agents. A dialog persists for some time and it is very important concept for user agents. Dialogs facilitate proper sequencing and routing of messages between SIP endpoints.

Dialogs are identified using Call-ID, From tag, and To tag. Messages that have these three identifiers same belong to the same dialog. We have shown that CSeq header field is used to order messages, in fact it is used to order messages within a dialog. The number must be monotonically increased for each message sent within a dialog otherwise the peer will handle it as out of order request or retransmission. In fact, the CSeq number identifies a transaction within a dialog because we have said that requests and associated responses are called transaction. This means that only one transaction in each direction can be active within a dialog. One could also say that a dialog is a sequence of transactions. Figure 6, “SIP Dialog” extends Figure 5, “SIP Transactions” to show which messages belong to the same dialog.

Figure 6. SIP Dialog


Some messages establish a dialog and some do not. This allows to explicitly express the relationship of messages and also to send messages that are not related to other messages outside a dialog. That is easier to implement because user agent don't have to keep the dialog state.

For instance, INVITE message establishes a dialog, because it will be later followed by BYE request which will tear down the session established by the INVITE. This BYE is sent within the dialog established by the INVITE.

But if a user agent sends a MESSAGE request, such a request doesn't establish any dialog. Any subsequent messages (even MESSAGE) will be sent independently of the previous one.

1.6.1. Dialogs Facilitate Routing

We have said that dialogs are also used to route the messages between user agents, let's describe this a little bit.

Let's suppose that user sip:[email protected] wants to talk to user sip:[email protected] He knows SIP address of the callee (sip:[email protected]) but this address doesn't say anything about current location of the user--i.e. the caller doesn't know to which host to send the request. Therefore the INVITE request will be sent to a proxy server.

The request will be sent from proxy to proxy until it reaches one that knows current location of the callee. This process is called routing. Once the request reaches the callee, the callee's user agent will create a response that will be sent back to the caller. Callee's user agent will also put Contact header field into the response which will contain the current location of the user. The original request also contained Contact header field which means that both user agents know the current location of the peer.

Because the user agents know location of each other, it is not necessary to send further requests to any proxy--they can be sent directly from user agent to user agent. That's exactly how dialogs facilitate routing.

Further messages within a dialog are sent directly from user agent to user agent. This is a significant performance improvement because proxies do not see all the messages within a dialog, they are used to route just the first request that establishes the dialog. The direct messages are also delivered with much smaller latency because a typical proxy usually implements complex routing logic. Figure 7, “SIP Trapezoid” contains an example of a message within a dialog (BYE) that bypasses the proxies.

Figure 7. SIP Trapezoid


1.6.2. Dialog Identifiers

We have already shown that dialog identifiers consist of three parts, Call-Id, From tag, and To tag, but it is not that clear why are dialog identifiers created exactly this way and who contributes which part.

Call-ID is so called call identifier. It must be a unique string that identifies a call. A call consists of one or more dialogs. Multiple user agents may respond to a request when a proxy along the path forks the request. Each user agent that sends a 2xx establishes a separate dialog with the caller. All such dialogs are part of the same call and have the same Call-ID.

From tag is generated by the caller and it uniquely identifies the dialog in the caller's user agent.

To tag is generated by a callee and it uniquely identifies, just like From tag, the dialog in the callee's user agent.

This hierarchical dialog identifier is necessary because a single call invitation can create several dialogs and caller must be able to distinguish them.

1.7. Typical SIP Scenarios

This section gives a brief overview of typical SIP scenarios that usually make up the SIP traffic.

Users must register themselves with a registrar to be reachable by other users. A registration comprises a REGISTER message followed by a 200 OK sent by registrar if the registration was successful. Registrations are usually authorized so a 407 reply can appear if the user didn't provide valid credentials. Figure 8, “REGISTER Message Flow” shows an example of registration.

Figure 8. REGISTER Message Flow


1.7.2. Session Invitation

A session invitation consists of one INVITE request which is usually sent to a proxy. The proxy sends immediately a 100 Trying reply to stop retransmissions and forwards the request further.

All provisional responses generated by callee are sent back to the caller. See 180 Ringing response in the call flow. The response is generated when callee's phone starts ringing.

Figure 9. 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. The session is established at this point.

1.7.3. Session Termination

Session termination is accomplished by sending a BYE request within dialog established bye INVITE. BYE messages are sent directly from one user agent to the other unless a proxy on the path of the INVITE request indicated that it wishes to stay on the path by using record routing (see Section 1.7.4, “Record Routing”.

Party wishing to tear down a session sends a BYE request to the other party involved in the session. The other party sends a 200 OK response to confirm the BYE and the session is terminated. See Figure 10, “BYE Message Flow (With and without Record Routing)”, left message flow.

All requests sent within a dialog are by default sent directly from one user agent to the other. Only requests outside a dialog traverse SIP proxies. This approach makes SIP network more scalable because only a small number of SIP messages hit the proxies.

There are certain situations in which a SIP proxy need to stay on the path of all further messages. For instance, proxies controlling a NAT box or proxies doing accounting need to stay on the path of BYE requests.

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. Such a proxy would insert Record-Route header field into SIP messages which contain address of the proxy. Messages sent within a dialog will then traverse all SIP proxies that put a Record-Route header field into the message.

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.

Figure 10. BYE Message Flow (With and without Record Routing)


Left message flow of Figure 10, “BYE Message Flow (With and without Record Routing)” show how a BYE (request within dialog established by INVITE) is sent directly to the other user agent when there is no Record-Route header field in the message. Right message flow show how the situation changes when the proxy puts a Record-Route header field into the message.

1.7.4.1. Strict versus Loose Routing

The way how record routing works has evolved. Record routing according to RFC2543 rewrote the Request-URI. That means the Request-URI always contained URI of the next hop (which can be either next proxy server which inserted Record-Route header field or destination user agent). Because of that it was necessary to save the original Request-URI as the last Route header field. This approach is called strict routing.

Loose routing, as specified in RFC3261, works in a little bit different way. The Request-URI is no more overwritten, it always contains URI of the destination user agent. If there are any Route header field in a message, than the message is sent to the URI from the topmost Route header field. This is significant change--Request-URI doesn't necessarily contain URI to which the request will be sent. In fact, loose routing is very similar to IP source routing.

Because transit from strict routing to loose routing would break backwards compatibility and older user agents wouldn't work, it is necessary to make loose routing backwards compatible. The backwards compatibility unfortunately adds a lot of overhead and is often source of major problems.

1.7.5. Event Subscription And Notification

The SIP specification has been extended to support a general mechanism allowing subscription to asynchronous events. Such evens can include SIP proxy statistics changes, presence information, session changes and so on.

The mechanism is used mainly to convey information on presence (willingness to communicate) of users. Figure 11, “Event Subscription And Notification” shows the basic message flow.

Figure 11. Event Subscription And Notification


A user agent interested in event notification sends a SUBSCRIBE message to a SIP server. The SUBSCRIBE message establishes a dialog and is immediately replied by the server using 200 OK response. At this point the dialog is established. The server sends a NOTIFY request to the user every time the event to which the user subscribed changes. NOTIFY messages are sent within the dialog established by the SUBSCRIBE.

Note that the first NOTIFY message in Figure 11, “Event Subscription And Notification” is sent regardless of any event that triggers notifications.

Subscriptions--as well as registrations--have limited lifespan and therefore must be periodically refreshed.

Instant messages are sent using MESSAGE request. MESSAGE requests do not establish a dialog and therefore they will always traverse the same set of proxies. This is the simplest form of sending instant messages. The text of the instant message is transported in the body of the SIP request.

Figure 12. Instant Messages


Sours: http://www.kamailio.org/docs/tutorials/sip-introduction/

A Dialog is a peer-to-peer relationship between two user agents. It represents a context that facilitates the sequencing of messages between the user agents and proper routing of requests between both of them. The following sequence of figures illustrates the creation of a dialog, the processing of requests during this dialog, and the termination of the dialog. This example shows two proxies that request to be maintained in the signalling path by inserting Record-Route header fields. Only the header fields relevant to the dialog and the routing of requests are shown in the SIP messages.

Note that 100 Trying provisional responses are not shown.

 

U1:
  • generates the INVITE request;
  • in this example, U1 is configured with a Route set containing a single URI, that of the outbound proxy (<sip:p1.atlanta.com;lr>); it applies DNS procedures to this URI for determining where to send the request.
P1:
  • inspects the Request-URI (sip:[email protected]) and does not change it because it is not responsible for the resource indicated in this URI;
  • sees that it is the first value in the Route header field so it removes that value;
  • adds a Record-Route header field value;
  • forwards the request to the resource indicated in the Request-URI (the route set is now empty) by applying DNS procedures.
P2:
  • inspects the Request-URI: it is responsible for "biloxi.com" so it runs a location service and rewrites the Request-URI (sip:[email protected]);
  • adds a Record-Route header field value;
  • forwards the request to the resource indicated in the Request-URI (the route set is empty) by applying DNS procedures.
Sours: https://www.tech-invite.com/fo-sip/tinv-fo-sip-dialog.html
  1. Kx85 oil
  2. Oakwood apartments arlington
  3. Mary poppins print

SIP - Proxies and Routing



As we know, a proxy server can be either stateless or stateful. Here, in this chapter, we will discuss more on proxy servers and SIP routing.

Stateless Proxy Server

A stateless proxy server simply forwards the message it receives. This kind of server does not store any information of the call or transaction.

  • Stateless proxies forget about the SIP request once it has been forwarded.
  • Transaction will be fast via stateless proxies.

Stateful Proxy Server

A stateful proxy server keeps track of every request and response that it receives. It can use the stored information in future, if required. It can retransmit the request if it does not receive a response from the other side.

  • Stateful proxies remember the request after it has been forwarded, so they can use it for advance routing. Stateful proxies maintain transaction state. Transaction implies transaction state, not call state.

  • Transaction is not as fast with stateful proxies as stateless.

  • Stateful proxies can fork and retransmit if required.(e.g.: call forward busy, for example).

Via and Record-route

Record-Route

The Record-Route header is inserted into requests by proxies that wanted to be in the path of subsequent requests for the same call-id. It is then used by the user agent to route subsequent requests.

Via

Via headers are inserted by servers into requests to detect loops and to help responses to find their way back to the client. This is helpful for only responses to reach their destination.

  • A UA himself generate and add its own address in a Via header field while sending request.

  • A proxy forwarding the request adds a Via header field containing its own address to the top of the list of Via header fields.

  • A proxy or UA generating a response to a request copies all the Via header fields from the request in order into the response, then sends the response to the address specified in the top Via header field.

  • A proxy receiving a response checks the top Via header field and matches its own address. If it does not match, the response has been discarded.

  • The top Via header field is then removed, and the response forwarded to the address specified in the next Via header field.

Via header fields contain protocolname, versionnumber, and transport (SIP/2.0/UDP, SIP/2.0/TCP, etc.) and contain portnumbers and parameters such as received, rport, branch.

  • A received tag is added to a Via header field if a UA or proxy receives the request from a different address than that specified in the top Via header field.

  • A branch parameter is added to Via header fields by UAs and proxies, which is computed as a hash function of the Request-URI, and the To, From, Call-ID, and CSeq number.

Sours: https://www.tutorialspoint.com/session_initiation_protocol/session_initiation_protocol_proxies_and_routing.htm
4. Volte call flow - SIP Call Flow - IMS Call procedure

LikeShareLinkedInTweet

Diagnosing some problems in the world of VoIP requires close inspection of the SIP messages being exchanged, but there are many occasions where a good understanding of loose routing will be invaluable. The headers that underpin loose routing are Contact, Record-Route and Route. In this post, I explain how they work and provide some insight into the way they interact.

Some Acronyms and terminology

UAC

UAS

SIP Proxy

URI *

Sequential Request

User Agent Client (for example, a VoIP handset)

User Agent Server (for example, an IP-PBX such as Asterisk)

A server that operates as an intermediate node between the UAC and the UAS

Uniform Resource Identifier. Typical format “sip:<username>@<domain>”

A SIP request that is part of an already established dialogue. It will have a “to-tag”. Sequential requests follow after the initial request that established the dialogue.

* The <domain> element is often shown as <host>, possibly to show it can be a domain or an IP address. It may also have a port number appended (after a colon separator). e.g. sip:[email protected]:5144

If you want to dig deeper into the terminology used to identify sub-components of the URI and see how it fits together with parameters in the context of a SIP header, then you may find this article interesting.

What is the function of the Contact header?

Contact headers contain a URI which should be used by other nodes and devices communicating with it (within the same dialogue) when they want to send it a SIP request. A Contact header is normally found in all SIP requests and is often found in SIP responses too. Its role is best illustrated by looking at examples.

Beginning with the simplest possible case: Two endpoints; one initiates a dialogue by sending a SIP request (e.g. INVITE) to the other. The Contact header is inserted into the SIP request by the device initiating the dialogue (the UAC). It is received by the downstream endpoint (the UAS), which must store the Contact address URI in case it needs to use it later in the dialogue.

Remember that the routing of SIP responses – such as “180 Ringing” or “200 OK” – is determined by the Via headers. The Contact header is used by downstream endpoints when they need to send SIP requests back upstream. However, it is equally valid for an upstream endpoint to use the URI from the downstream device’s Contact header in sequential requests, once it has received it.

When might we expect to see an endpoint send a request upstream as shown above? An obvious example is a BYE request. If the called party hangs up first, a BYE request would be sent upstream to the caller’s device to tell it that call has ended. The Contact header supplied during the call setup phase tells the called device how to address the calling device in such a situation.

It is important to note that the Contact header defines a URI, not just an IP address and port. It is usual for the calling device to expect the Request-URI (R-URI) in an upstream request to use the same <username> element that it wrote in the original Contact header URI. However, many devices will be tolerant and accept a request where the domain of the URI has changed. This is important because it allows intermediate proxies to fix the Contact address when the UAC device is behind NAT (discussed in detail here). The Contact header may also include parameters and you would expect these to be copied to the R-URI on an upstream request. Here is an example of a Contact header from a device behind NAT which also includes two parameters:

Contact: "John Quick" <sip:[email protected]:2048;line=n01ly175;transport=tcp>

Introducing the Record-Route header

The above diagrams and example illustrate the core principles using a highly simplified case, but unfortunately it doesn’t bear much resemblance to the real world because, other than LAN-based extensions on a PBX, it is quite unusual for two endpoints to communicate directly with each other. To make it more realistic, we need to at least include a Proxy server or SBC in the communication path between the calling and the called devices.

The standard solution used by SIP Proxy servers involves adding another header, a Record-Route header, to identify itself as an intermediate node.

Record-Route headers are reborn as Route headers when a request is sent upstream. More on this later, but first I must point out a pertinent side-issue before moving on. It is that the SIP standards describe two different techniques that Record-Route headers (and their counter-part Route headers) can use:

  1. strict routing
  2. loose routing

Within my blog posts/wiki articles, including this one, I only discuss loose routing. If you want to know about strict routing, please find information from other online resources. I’m sure a Google search will find plenty of material on this topic. So please just accept that in all my wiki articles, loose routing is assumed. Now, let’s get back to the main topic of this post.

How Record-Route headers are used

At this point, I am going to deliberately increase the complexity of the situation because it helps to illustrate how Record-Route headers operate in practice. What happens when there is more than one Proxy server?

Each Proxy in the chain adds a new Record-Route header containing its own address. It always adds it above any existing RR headers – the order is important. In the example above, when the SIP request arrives at the UAS, it contains three RR headers. The whole set of RR headers describes the path through all intermediate nodes. Combined with the Contact header, this provides a complete description of the upstream path that leads back to the calling device.

The UAS has a complete description of the path back to the UAC, but at this point the UAC doesn’t have any knowledge of the path, the intermediate nodes or even the address of the UAS. It needs to know the path too, for example when it wants to send more requests to the UAS within the current dialogue. So how can this information be exchanged? The answer is fairly simple – the UAS includes a complete copy of all the Record-Route headers in its response. It also includes its own Contact header in the response. The path that the response follows is defined by the Via headers – the RR headers are present in the response but do not influence its transmission path.

So now, both the UAC and the UAS have a copy of the full set of Record-Route headers. This is essential for loose routing to work and it happens at the start of the dialogue. Here is an edited example of a real-world SIP INVITE request containing two Record-Route headers:

INVITE sip:[email protected]:5060 SIP/2.0
Record-Route: <sip:82.0.128.19:5060;lr>
Record-Route: <sip:89.200.14.123:5060;lr;MPXON=Y>
Via: SIP/2.0/UDP 82.0.128.19:5060;branch=z9hG4bKf01e.56789d1.0
Via: SIP/2.0/UDP 89.200.14.123:5060;branch=z9hG4bKf01e.f9f91e21.0
Via: SIP/2.0/UDP 192.168.24.12:5144;received=86.4.139.77;branch=z9hG4bK161987113;rport=4454
From: “John Quick” <sip:[email protected]:5061>;tag=2014274981
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 21 INVITE
Contact: “John Quick” <sip:[email protected]:4454>

Note how the Record-Route headers all include the parameter “lr”. This is very important – it shows that loose routing is to be used. One of the RR headers also has a custom parameter “MPXON=Y” which was used to show that a media proxy was active. You would expect to see exactly the same two Record-Route headers in the “200 OK” response when the call is answered.

Once the “Route Set” has been established, it is remembered by both end points. Once the dialogue is established, the proxies should not insert any more Record-Route headers after that initial transaction. Instead, all the sequential SIP requests should contain Route headers.

Introducing Route headers

In a sequential request, the Route Set is used to create a set of Route headers. The sequence of these headers is important – the upstream server will invert the order, but a downstream server does not. The next diagram is a representation of a downstream sequential SIP request using loose routing:

…and this is the equivalent diagram for an upstream request:

A quick explanation of the loose routing mechanism

The path for the request is determined by the embedded Route headers. When they receive a loose routed request, the intermediate nodes (Proxies) should find their own address in the topmost Route header. It is their responsibility to then strip off this topmost Route header and check if there are any more. If there are more Route headers, the next one is then used to determine the address of the next node in the path. This process is repeated until the last-but-one node is reached. At this point, all Route headers have been used and the final hop uses the Request-URI for routing.

Some variations you may encounter

Double RR headers

When a Proxy receives a request on one network interface and sends it onwards using a different interface (e.g. WAN to LAN), this will normally require the addition of an extra Record-Route header. i.e. the Proxy must add two RR headers where you might normally expect it to add one. The same happens when a Proxy transcodes from one transport protocol to another – for example, if it receives a WebRTC request and forwards it as TCP. In cases where it adds two Record-Route headers, it should also add a parameter “;r2=on”. Here is an example:

RFC 5658 is the official specification document for using double RR headers in these special situations.

Topology Hiding

The TOPOLOGY_HIDING module of OpenSIPS, when used, will not use Record-Route and Route headers in the way explained here. Instead, it stores information about upstream and downstream paths in memory and inserts a unique key value into the Contact header that it uses later to recover the required information from memory.

The “received” parameter

In some situations, you may see a “received” parameter in a Route header. It is used to specify an address that is different to the main address defined in the header. This format may sometimes be used if loose routing is being used to reach a device behind NAT where the Contact URI for the device gives one IP address but the network connection requires the use of a different address – e.g. the Contact URI uses a LAN address and the only way to reach it is through a public IP address on the external port of a NAT router.

The “alias” parameter, connection re-use and RFC 5923

When the connection to a SIP proxy is made using TCP or TLS, it is possible that the port shown in a Route header will be ignored because the proxy prefers to re-use a pre-existing connection. This behaviour is somewhat tricky to explain in detail and I would refer you to RFC 5923 if you want to understand it. Strictly it should only happen if the “alias” parameter was present in the Via received in an earlier request, but OpenSIPS also has a core function, force_tcp_alias(), that will trigger the same behaviour even if the “alias” parameter was not present.

Implementation in OpenSIPS

To handle loose routing in OpenSIPS, you must have the TM and RR modules loaded. The RR module provides functions for adding Record-Route headers to an initial request and another function to deal with Route headers in a received sequential request.

OpenSIPS defines a core property for SIP requests called “the destination”. In xlog statements you can print its value using $du. It is distinct from the Request-URI (printed using $ru) and, if present, it takes precedence in determining where a request is relayed when the t_relay() function is called. If no destination is set, the request will be routed according to the R-URI.

The loose-route() function detects if Route headers are present, strips off the topmost header (or the topmost two if “r2=on” is detected), then looks to see if there are any more Route headers. If it finds at least one, the network address defined in the new topmost header is assigned to “the destination” ($du). Your script must still use t_relay() to send the request onwards. The following flow chart (which is highly simplified) shows how a typical OpenSIPS script might process requests using the functions mentioned above:

Further reading and feedback

This topic is quite well covered on the Internet by various authors from around the world, so if you want to supplement what you learnt here with additional information, a Google search should bring you plenty of results. If you want to study the detailed specifications, then look for the following RFC’s:

  • RFC 3261: SIP: Session Initiation Protocol
  • RFC 5658: Using double Record-Route headers when protocol or interface changes
  • RFC 3327: About using Path Headers to identify intermediate Proxies in registrations

At the start of 2021, I wrote a series of articles examining when and how Contact address fixing should be used in OpenSIPS. Here are the links:

Introduction to the topic: https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-1/

About responses & Via’s: https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-2/

About Contact fixing: https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/

Please leave comments using the Comment facility below. Also, please consider using the Like buttons either at the start of the article (Facebook Recommendation) or just below (which is purely local so I can see which posts are most popular). Thanks.

Categories OpenSIPS, SIPTags Contact, Contact header, Kamailio, Loose routing, OpenSIPS, Record-Route, Route header, SIP, SIP ProxySours: https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explained/

Header sip route

Network Working Group J. Rosenberg Request for Comments: 3261 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R. Sparks dynamicsoft M. Handley ICIR E. Schooler AT&T June 2002 SIP: Session Initiation Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. Rosenberg, et. al. Standards Track [Page 1]
RFC 3261 SIP: Session Initiation Protocol June 2002 Table of Contents 1 Introduction ........................................ 82 Overview of SIP Functionality ....................... 93 Terminology ......................................... 104 Overview of Operation ............................... 105 Structure of the Protocol ........................... 186 Definitions ......................................... 207 SIP Messages ........................................ 267.1 Requests ............................................ 277.2 Responses ........................................... 287.3 Header Fields ....................................... 297.3.1 Header Field Format ................................. 307.3.2 Header Field Classification ......................... 327.3.3 Compact Form ........................................ 327.4 Bodies .............................................. 337.4.1 Message Body Type ................................... 337.4.2 Message Body Length ................................. 337.5 Framing SIP Messages ................................ 348 General User Agent Behavior ......................... 348.1 UAC Behavior ........................................ 358.1.1 Generating the Request .............................. 358.1.1.1 Request-URI ......................................... 358.1.1.2 To .................................................. 368.1.1.3 From ................................................ 378.1.1.4 Call-ID ............................................. 378.1.1.5 CSeq ................................................ 388.1.1.6 Max-Forwards ........................................ 388.1.1.7 Via ................................................. 398.1.1.8 Contact ............................................. 408.1.1.9 Supported and Require ............................... 408.1.1.10 Additional Message Components ....................... 418.1.2 Sending the Request ................................. 418.1.3 Processing Responses ................................ 428.1.3.1 Transaction Layer Errors ............................ 428.1.3.2 Unrecognized Responses .............................. 428.1.3.3 Vias ................................................ 438.1.3.4 Processing 3xx Responses ............................ 438.1.3.5 Processing 4xx Responses ............................ 458.2 UAS Behavior ........................................ 468.2.1 Method Inspection ................................... 468.2.2 Header Inspection ................................... 468.2.2.1 To and Request-URI .................................. 468.2.2.2 Merged Requests ..................................... 478.2.2.3 Require ............................................. 478.2.3 Content Processing .................................. 488.2.4 Applying Extensions ................................. 498.2.5 Processing the Request .............................. 49Rosenberg, et. al. Standards Track [Page 2]
RFC 3261 SIP: Session Initiation Protocol June 20028.2.6 Generating the Response ............................. 498.2.6.1 Sending a Provisional Response ...................... 498.2.6.2 Headers and Tags .................................... 508.2.7 Stateless UAS Behavior .............................. 508.3 Redirect Servers .................................... 519 Canceling a Request ................................. 539.1 Client Behavior ..................................... 539.2 Server Behavior ..................................... 5510 Registrations ....................................... 5610.1 Overview ............................................ 5610.2 Constructing the REGISTER Request ................... 5710.2.1 Adding Bindings ..................................... 59 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 10.2.1.2 Preferences among Contact Addresses ................. 6110.2.2 Removing Bindings ................................... 6110.2.3 Fetching Bindings ................................... 6110.2.4 Refreshing Bindings ................................. 6110.2.5 Setting the Internal Clock .......................... 6210.2.6 Discovering a Registrar ............................. 6210.2.7 Transmitting a Request .............................. 6210.2.8 Error Responses ..................................... 6310.3 Processing REGISTER Requests ........................ 6311 Querying for Capabilities ........................... 6611.1 Construction of OPTIONS Request ..................... 6711.2 Processing of OPTIONS Request ....................... 6812 Dialogs ............................................. 6912.1 Creation of a Dialog ................................ 7012.1.1 UAS behavior ........................................ 7012.1.2 UAC Behavior ........................................ 7112.2 Requests within a Dialog ............................ 7212.2.1 UAC Behavior ........................................ 7312.2.1.1 Generating the Request .............................. 7312.2.1.2 Processing the Responses ............................ 7512.2.2 UAS Behavior ........................................ 7612.3 Termination of a Dialog ............................. 7713 Initiating a Session ................................ 7713.1 Overview ............................................ 7713.2 UAC Processing ...................................... 7813.2.1 Creating the Initial INVITE ......................... 7813.2.2 Processing INVITE Responses ......................... 8113.2.2.1 1xx Responses ....................................... 8113.2.2.2 3xx Responses ....................................... 8113.2.2.3 4xx, 5xx and 6xx Responses .......................... 8113.2.2.4 2xx Responses ....................................... 8213.3 UAS Processing ...................................... 8313.3.1 Processing of the INVITE ............................ 8313.3.1.1 Progress ............................................ 8413.3.1.2 The INVITE is Redirected ............................ 84Rosenberg, et. al. Standards Track [Page 3]
RFC 3261 SIP: Session Initiation Protocol June 200213.3.1.3 The INVITE is Rejected .............................. 8513.3.1.4 The INVITE is Accepted .............................. 8514 Modifying an Existing Session ....................... 8614.1 UAC Behavior ........................................ 8614.2 UAS Behavior ........................................ 8815 Terminating a Session ............................... 8915.1 Terminating a Session with a BYE Request ............ 9015.1.1 UAC Behavior ........................................ 9015.1.2 UAS Behavior ........................................ 9116 Proxy Behavior ...................................... 9116.1 Overview ............................................ 9116.2 Stateful Proxy ...................................... 9216.3 Request Validation .................................. 9416.4 Route Information Preprocessing ..................... 9616.5 Determining Request Targets ......................... 9716.6 Request Forwarding .................................. 9916.7 Response Processing ................................. 10716.8 Processing Timer C .................................. 11416.9 Handling Transport Errors ........................... 11516.10 CANCEL Processing ................................... 11516.11 Stateless Proxy ..................................... 11616.12 Summary of Proxy Route Processing ................... 11816.12.1 Examples ............................................ 11816.12.1.1 Basic SIP Trapezoid ................................. 11816.12.1.2 Traversing a Strict-Routing Proxy ................... 12016.12.1.3 Rewriting Record-Route Header Field Values .......... 12117 Transactions ........................................ 12217.1 Client Transaction .................................. 12417.1.1 INVITE Client Transaction ........................... 12517.1.1.1 Overview of INVITE Transaction ...................... 12517.1.1.2 Formal Description .................................. 12517.1.1.3 Construction of the ACK Request ..................... 12917.1.2 Non-INVITE Client Transaction ....................... 13017.1.2.1 Overview of the non-INVITE Transaction .............. 13017.1.2.2 Formal Description .................................. 13117.1.3 Matching Responses to Client Transactions ........... 13217.1.4 Handling Transport Errors ........................... 13317.2 Server Transaction .................................. 13417.2.1 INVITE Server Transaction ........................... 13417.2.2 Non-INVITE Server Transaction ....................... 13717.2.3 Matching Requests to Server Transactions ............ 13817.2.4 Handling Transport Errors ........................... 14118 Transport ........................................... 14118.1 Clients ............................................. 14218.1.1 Sending Requests .................................... 14218.1.2 Receiving Responses ................................. 14418.2 Servers ............................................. 14518.2.1 Receiving Requests .................................. 145Rosenberg, et. al. Standards Track [Page 4]
RFC 3261 SIP: Session Initiation Protocol June 200218.2.2 Sending Responses ................................... 14618.3 Framing ............................................. 14718.4 Error Handling ...................................... 14719 Common Message Components ........................... 14719.1 SIP and SIPS Uniform Resource Indicators ............ 14819.1.1 SIP and SIPS URI Components ......................... 14819.1.2 Character Escaping Requirements ..................... 15219.1.3 Example SIP and SIPS URIs ........................... 15319.1.4 URI Comparison ...................................... 15319.1.5 Forming Requests from a URI ......................... 15619.1.6 Relating SIP URIs and tel URLs ...................... 15719.2 Option Tags ......................................... 15819.3 Tags ................................................ 15920 Header Fields ....................................... 15920.1 Accept .............................................. 16120.2 Accept-Encoding ..................................... 16320.3 Accept-Language ..................................... 16420.4 Alert-Info .......................................... 16420.5 Allow ............................................... 16520.6 Authentication-Info ................................. 16520.7 Authorization ....................................... 16520.8 Call-ID ............................................. 16620.9 Call-Info ........................................... 16620.10 Contact ............................................. 16720.11 Content-Disposition ................................. 16820.12 Content-Encoding .................................... 16920.13 Content-Language .................................... 16920.14 Content-Length ...................................... 16920.15 Content-Type ........................................ 17020.16 CSeq ................................................ 17020.17 Date ................................................ 17020.18 Error-Info .......................................... 17120.19 Expires ............................................. 17120.20 From ................................................ 17220.21 In-Reply-To ......................................... 17220.22 Max-Forwards ........................................ 17320.23 Min-Expires ......................................... 17320.24 MIME-Version ........................................ 17320.25 Organization ........................................ 17420.26 Priority ............................................ 17420.27 Proxy-Authenticate .................................. 17420.28 Proxy-Authorization ................................. 17520.29 Proxy-Require ....................................... 17520.30 Record-Route ........................................ 17520.31 Reply-To ............................................ 17620.32 Require ............................................. 17620.33 Retry-After ......................................... 17620.34 Route ............................................... 177Rosenberg, et. al. Standards Track [Page 5]
RFC 3261 SIP: Session Initiation Protocol June 200220.35 Server .............................................. 17720.36 Subject ............................................. 17720.37 Supported ........................................... 17820.38 Timestamp ........................................... 17820.39 To .................................................. 17820.40 Unsupported ......................................... 17920.41 User-Agent .......................................... 17920.42 Via ................................................. 17920.43 Warning ............................................. 18020.44 WWW-Authenticate .................................... 18221 Response Codes ...................................... 18221.1 Provisional 1xx ..................................... 18221.1.1 100 Trying .......................................... 18321.1.2 180 Ringing ......................................... 18321.1.3 181 Call Is Being Forwarded ......................... 18321.1.4 182 Queued .......................................... 18321.1.5 183 Session Progress ................................ 18321.2 Successful 2xx ...................................... 18321.2.1 200 OK .............................................. 18321.3 Redirection 3xx ..................................... 18421.3.1 300 Multiple Choices ................................ 18421.3.2 301 Moved Permanently ............................... 18421.3.3 302 Moved Temporarily ............................... 18421.3.4 305 Use Proxy ....................................... 18521.3.5 380 Alternative Service ............................. 18521.4 Request Failure 4xx ................................. 18521.4.1 400 Bad Request ..................................... 18521.4.2 401 Unauthorized .................................... 18521.4.3 402 Payment Required ................................ 18621.4.4 403 Forbidden ....................................... 18621.4.5 404 Not Found ....................................... 18621.4.6 405 Method Not Allowed .............................. 18621.4.7 406 Not Acceptable .................................. 18621.4.8 407 Proxy Authentication Required ................... 18621.4.9 408 Request Timeout ................................. 18621.4.10 410 Gone ............................................ 18721.4.11 413 Request Entity Too Large ........................ 18721.4.12 414 Request-URI Too Long ............................ 18721.4.13 415 Unsupported Media Type .......................... 18721.4.14 416 Unsupported URI Scheme .......................... 18721.4.15 420 Bad Extension ................................... 18721.4.16 421 Extension Required .............................. 18821.4.17 423 Interval Too Brief .............................. 18821.4.18 480 Temporarily Unavailable ......................... 18821.4.19 481 Call/Transaction Does Not Exist ................. 18821.4.20 482 Loop Detected ................................... 18821.4.21 483 Too Many Hops ................................... 18921.4.22 484 Address Incomplete .............................. 189Rosenberg, et. al. Standards Track [Page 6]
RFC 3261 SIP: Session Initiation Protocol June 200221.4.23 485 Ambiguous ....................................... 18921.4.24 486 Busy Here ....................................... 18921.4.25 487 Request Terminated .............................. 19021.4.26 488 Not Acceptable Here ............................. 19021.4.27 491 Request Pending ................................. 19021.4.28 493 Undecipherable .................................. 19021.5 Server Failure 5xx .................................. 19021.5.1 500 Server Internal Error ........................... 19021.5.2 501 Not Implemented ................................. 19121.5.3 502 Bad Gateway ..................................... 19121.5.4 503 Service Unavailable ............................. 19121.5.5 504 Server Time-out ................................. 19121.5.6 505 Version Not Supported ........................... 19221.5.7 513 Message Too Large ............................... 19221.6 Global Failures 6xx ................................. 19221.6.1 600 Busy Everywhere ................................. 19221.6.2 603 Decline ......................................... 19221.6.3 604 Does Not Exist Anywhere ......................... 19221.6.4 606 Not Acceptable .................................. 19222 Usage of HTTP Authentication ........................ 19322.1 Framework ........................................... 19322.2 User-to-User Authentication ......................... 19522.3 Proxy-to-User Authentication ........................ 19722.4 The Digest Authentication Scheme .................... 19923 S/MIME .............................................. 20123.1 S/MIME Certificates ................................. 20123.2 S/MIME Key Exchange ................................. 20223.3 Securing MIME bodies ................................ 205 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP ....................................... 207 23.4.1 Integrity and Confidentiality Properties of SIP Headers ............................................. 20723.4.1.1 Integrity ........................................... 20723.4.1.2 Confidentiality ..................................... 20823.4.2 Tunneling Integrity and Authentication .............. 20923.4.3 Tunneling Encryption ................................ 21124 Examples ............................................ 21324.1 Registration ........................................ 21324.2 Session Setup ....................................... 21425 Augmented BNF for the SIP Protocol .................. 21925.1 Basic Rules ......................................... 219 26 Security Considerations: Threat Model and Security Usage Recommendations ............................... 23226.1 Attacks and Threat Models ........................... 23326.1.1 Registration Hijacking .............................. 23326.1.2 Impersonating a Server .............................. 23426.1.3 Tampering with Message Bodies ....................... 23526.1.4 Tearing Down Sessions ............................... 235Rosenberg, et. al. Standards Track [Page 7]
RFC 3261 SIP: Session Initiation Protocol June 200226.1.5 Denial of Service and Amplification ................. 23626.2 Security Mechanisms ................................. 23726.2.1 Transport and Network Layer Security ................ 23826.2.2 SIPS URI Scheme ..................................... 23926.2.3 HTTP Authentication ................................. 24026.2.4 S/MIME .............................................. 24026.3 Implementing Security Mechanisms .................... 24126.3.1 Requirements for Implementers of SIP ................ 24126.3.2 Security Solutions .................................. 24226.3.2.1 Registration ........................................ 24226.3.2.2 Interdomain Requests ................................ 24326.3.2.3 Peer-to-Peer Requests ............................... 24526.3.2.4 DoS Protection ...................................... 24626.4 Limitations ......................................... 24726.4.1 HTTP Digest ......................................... 24726.4.2 S/MIME .............................................. 24826.4.3 TLS ................................................. 24926.4.4 SIPS URIs ........................................... 24926.5 Privacy ............................................. 25127 IANA Considerations ................................. 25227.1 Option Tags ......................................... 25227.2 Warn-Codes .......................................... 25227.3 Header Field Names .................................. 25327.4 Method and Response Codes ........................... 253 27.5 The "message/sip" MIME type. ....................... 25427.6 New Content-Disposition Parameter Registrations ..... 25528 Changes From RFC 2543 ............................... 25528.1 Major Functional Changes ............................ 25528.2 Minor Functional Changes ............................ 26029 Normative References ................................ 26130 Informative References .............................. 262A Table of Timer Values ............................... 265 Acknowledgments ................................................ 266 Authors' Addresses ............................................. 267 Full Copyright Statement ....................................... 2691 Introduction There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by Rosenberg, et. al. Standards Track [Page 8]
RFC 3261 SIP: Session Initiation Protocol June 2002 enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established. 2 Overview of SIP Functionality SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility [27] - users can maintain a single externally visible identifier regardless of their network location. SIP supports five facets of establishing and terminating multimedia communications: User location: determination of the end system to be used for communication; User availability: determination of the willingness of the called party to engage in communications; User capabilities: determination of the media and media parameters to be used; Session setup: "ringing", establishment of session parameters at both called and calling party; Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC2326 [29]) for controlling delivery of streaming media, the Media Rosenberg, et. al. Standards Track [Page 9]
RFC 3261 SIP: Session Initiation Protocol June 2002 Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols. SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services. SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities. The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services. SIP works with both IPv4 and IPv6. 3 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. 4 Overview of Operation This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements. Rosenberg, et. al. Standards Track [Page 10]
RFC 3261 SIP: Session Initiation Protocol June 2002 The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established. Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each message is labeled with the letter "F" and a number for reference by the text.) In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the "SIP trapezoid" as shown by the geometric shape of the dotted lines in Figure 1. Alice "calls" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section19.1. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:[email protected], where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:[email protected] Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be sips:[email protected] A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee. SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice's address, and information about the type of session that Alice wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this: Rosenberg, et. al. Standards Track [Page 11]
RFC 3261 SIP: Session Initiation Protocol June 2002 atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below: Rosenberg, et. al. Standards Track [Page 12]
RFC 3261 SIP: Session Initiation Protocol June 2002 Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction. To contains a display name (Bob) and a SIP or SIPS URI (sip:[email protected]) towards which the request was originally directed. Display names are described in RFC 2822 [3]. From also contains a display name (Alice) and a SIP or SIPS URI (sip:[email protected]) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the softphone. It is used for identification purposes. Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests. Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. Content-Type contains a description of the message body (not shown). Content-Length contains an octet (byte) count of the message body. The complete set of SIP header fields is defined in Section 20. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the Rosenberg, et. al. Standards Track [Page 13]
RFC 3261 SIP: Session Initiation Protocol June 2002 example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message. Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example. The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. (We shall see in the next section how this database can be populated.) The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone. Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being Rosenberg, et. al. Standards Track [Page 14]
RFC 3261 SIP: Session Initiation Protocol June 2002 maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE. When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen. In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The complete list of SIP response codes is in Section21. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob's SIP phone has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future Rosenberg, et. al. Standards Track [Page 15]
RFC 3261 SIP: Session Initiation Protocol June 2002 requests and responses in this call. The Contact header field contains a URI at which Bob can be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information. In addition to DNS and location service lookups shown in this example, proxy servers can make flexible "routing decisions" to decide where to send a request. For example, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob's voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking. In this case, the 200 (OK) is routed back through the two proxies and is received by Alice's softphone, which then stops the ringback tone and indicates that the call has been answered. Finally, Alice's softphone sends an acknowledgement message, ACK, to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13. Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages. During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section14. Rosenberg, et. al. Standards Track [Page 16]
RFC 3261 SIP: Session Initiation Protocol June 2002 At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to Alice's softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent - an ACK is only sent in response to a response to an INVITE request. The reasons for this special handling for INVITE will be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking. For this reason, request handling in SIP is often classified as either INVITE or non- INVITE, referring to all other methods besides INVITE. Full details on session termination are in Section 15. Section 24.2 describes the messages shown in Figure 1 in full. In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record- Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob's SIP phone and (due to the Record-Route header field being passed back in the 200 (OK)) Alice's softphone and stored for the duration of the dialog. The biloxi.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features. Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:[email protected]) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical. Bob is not limited to registering from a single device. For example, both his SIP phone at home and the one in the office could send registrations. This information is stored together in the location Rosenberg, et. al. Standards Track [Page 17]
RFC 3261 SIP: Session Initiation Protocol June 2002 service and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be registered on a single device at the same time. The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator. Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as discussed in Section26. The complete set of SIP message details for this registration example is in Section 24.1. Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, will be introduced in later sections. 5 Structure of the Protocol SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. The protocol behavior is described as layers for the purpose of presentation, allowing the description of functions common across elements in a single section. It does not dictate an implementation in any way. When we say that an element "contains" a layer, we mean it is compliant to the set of rules defined by that layer. Not every element specified by the protocol contains every layer. Furthermore, the elements specified by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical elements, perhaps even on a transaction-by-transaction basis. The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-Naur Form grammar (BNF). The complete BNF is specified in Section 25; an overview of a SIP message's structure can be found in Section 7. Rosenberg, et. al. Standards Track [Page 18]
RFC 3261 SIP: Session Initiation Protocol June 2002 The second layer is the transport layer. It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. All SIP elements contain a transport layer. The transport layer is described in Section 18. The third layer is the transaction layer. Transactions are a fundamental component of SIP. A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Discussion of transactions can be found in Section 17. User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction layer. The transaction layer has a client component (referred to as a client transaction) and a server component (referred to as a server transaction), each of which are represented by a finite state machine that is constructed to process a particular request. The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction user. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request. A TU that creates a client transaction can also cancel it. When a client cancels a transaction, it requests that the server stop further processing, revert to the state that existed before the transaction was initiated, and generate a specific error response to that transaction. This is done with a CANCEL request, which constitutes its own transaction, but references the transaction to be cancelled (Section 9). The SIP elements, that is, user agent clients and servers, stateless and stateful proxies and registrars, contain a core that distinguishes them from each other. Cores, except for the stateless proxy, are transaction users. While the behavior of the UAC and UAS cores depends on the method, there are some common rules for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they govern the processing of a request and generating a response. Since registrations play an important role in SIP, a UAS that handles a REGISTER is given the special name registrar. Section 10 describes UAC and UAS core behavior for the REGISTER method. Section 11 describes UAC and UAS core behavior for the OPTIONS method, used for determining the capabilities of a UA. Rosenberg, et. al. Standards Track [Page 19]
RFC 3261 SIP: Session Initiation Protocol June 2002 Certain other requests are sent within a dialog. A dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages and proper routing of requests between the user agents. The INVITE method is the only way defined in this specification to establish a dialog. When a UAC sends a request that is within the context of a dialog, it follows the common UAC rules as discussed in Section 8 but also the rules for mid-dialog requests. Section 12 discusses dialogs and presents the procedures for their construction and maintenance, in addition to construction of requests within a dialog. The most important method in SIP is the INVITE method, which is used to establish a session between participants. A session is a collection of participants, and streams of media between them, for the purposes of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs. Section 14 discusses how characteristics of that session are modified through the use of an INVITE request within a dialog. Finally, section 15 discusses how a session is terminated. The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core (Section 9 describes cancellation, which applies to both UA core and proxy core). Section 16 discusses the proxy element, which facilitates routing of messages between user agents. 6 Definitions The following terms have special significance for SIP. Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user. Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Rosenberg, et. al. Standards Track [Page 20]
RFC 3261 SIP: Session Initiation Protocol June 2002 Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Call Leg: Another name for a dialog [31]; no longer used in this specification. Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients. Conference: A multimedia session (see below) that contains multiple participants. Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users. Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC2543. Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server. Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final. Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields. Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a Rosenberg, et. al. Standards Track [Page 21]
RFC 3261 SIP: Session Initiation Protocol June 2002 given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row. Header Field Value: A header field value is a single value; a header field consists of zero or more header field values. Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration. Informational Response: Same as a provisional response. Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time it sends the initial INVITE that established a dialog until the termination of that dialog. Invitation: An INVITE request. Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE. Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings. Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol. Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from Rosenberg, et. al. Standards Track [Page 22]
RFC 3261 SIP: Session Initiation Protocol June 2002 the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router. Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. Method: The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE. Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols. Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request. Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests. Provisional Response: A response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response. Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs. Rosenberg, et. al. Standards Track [Page 23]
RFC 3261 SIP: Session Initiation Protocol June 2002 Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK, or CANCEL. Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation. Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server. Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing). Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured. Server: A server is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and registrars. Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search. Session: From the SDP specification: "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session." (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field. SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response Rosenberg, et. al. Standards Track [Page 24]
RFC 3261 SIP: Session Initiation Protocol June 2002 sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls [email protected] The example.com proxy forwards it to Joe's PC, which in turn, forwards it to [email protected] This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition. Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction stateful proxy. The behavior of a stateful proxy is further defined in Section 16. A (transaction) stateful proxy is not the same as a call stateful proxy. Stateless Proxy: A logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream. Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in this specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers. Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog. Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core. Rosenberg, et. al. Standards Track [Page 25]
RFC 3261 SIP: Session Initiation Protocol June 2002 Upstream: A direction of message forwarding within a transaction that refers to the direction that responses flow from the user agent server back to the user agent client. URL-encoded: A character string encoded according to RFC 2396, Section 2.4 [5]. User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. UAC Core: The set of processing functions required of a UAC that reside above the transaction and transport layers. User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. UAS Core: The set of processing functions required at a UAS that resides above the transaction and transport layers. User Agent (UA): A logical entity that can act as both a user agent client and user agent server. The role of UAC and UAS, as well as proxy and redirect servers, are defined on a transaction-by-transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request. Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application. 7 SIP Messages SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]). Rosenberg, et. al. Standards Track [Page 26]
RFC 3261 SIP: Session Initiation Protocol June 2002 A SIP message is either a request from a client to a server, or a response from a server to a client. Both Request (section 7.1) and Response (section 7.2) messages use the basic format of RFC 2822 [3], even though the syntax differs in character set and syntax specifics. (SIP allows header fields that would not be valid RFC 2822 header fields, for example.) Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not. Except for the above difference in character sets, much of SIP's message and header field syntax is identical to HTTP/1.1. Rather than repeating the syntax and semantics here, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). However, SIP is not an extension of HTTP. 7.1 Requests SIP requests are distinguished by having a Request-Line for a start- line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character. The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements. Request-Line = Method SP Request-URI SP SIP-Version CRLF Method: This specification defines six methods: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods. Rosenberg, et. al. Standards Track [Page 27]
RFC 3261 SIP: Session Initiation Protocol June 2002 Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in "<>". SIP elements MAY support Request-URIs with schemes other than "sip" and "sips", for example the "tel" URI scheme of RFC2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of "SIP/2.0". The SIP-Version string is case-insensitive, but implementations MUST send upper-case. Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference. 7.2 Responses SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence. Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request. Rosenberg, et. al. Standards Track [Page 28]
RFC 3261 SIP: Session Initiation Protocol June 2002 The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows six values for the first digit: 1xx: Provisional -- request received, continuing to process the request; 2xx: Success -- the action was successfully received, understood, and accepted; 3xx: Redirection -- further action needs to be taken in order to complete the request; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. Section 21 defines these classes and describes the individual codes. 7.3 Header Fields SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar. [H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. Specifically, any SIP header whose grammar is of the form header = "header-name" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. The Contact header field allows a comma-separated list unless the header field value is "*". Rosenberg, et. al. Standards Track [Page 29]
RFC 3261 SIP: Session Initiation Protocol June 20027.3.1 Header Field Format Header fields follow the same generic header format as that given in Section 2.2 of RFC 2822 [3]. Each header field consists of a field name followed by a colon (":") and the field value. field-name: field-value The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of whitespace on either side of the colon; however, implementations should avoid spaces between the field name and the colon and use a single space (SP) between the colon and the field-value. Subject: lunch Subject : lunch Subject :lunch Subject: lunch Thus, the above are all valid and equivalent, but the last is the preferred form. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character. Thus, the following are equivalent: Subject: I know you're there, pick up the phone and talk to me! Subject: I know you're there, pick up the phone and talk to me! The relative order of header fields with different field names is not significant. However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header Rosenberg, et. al. Standards Track [Page 30]
RFC 3261 SIP: Session Initiation Protocol June 2002 field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. The following groups of header field rows are valid and equivalent: Route: <sip:[email protected]> Subject: Lunch Route: <sip:[email protected]> Route: <sip:[email protected]> Route: <sip:[email protected]>, <sip:[email protected]> Route: <sip:[email protected]> Subject: Lunch Subject: Lunch Route: <sip:[email protected]>, <sip:[email protected]>, <sip:[email protected]> Each of the following blocks is valid but not equivalent to the others: Route: <sip:[email protected]> Route: <sip:[email protected]> Route: <sip:[email protected]> Route: <sip:[email protected]> Route: <sip:[email protected]> Route: <sip:[email protected]> Route: <sip:[email protected]>,<sip:[email protected]>, <sip:[email protected]> The format of a header field-value is defined per header-name. It will always be either an opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs: field-name: field-value *(;parameter-name=parameter-value) Rosenberg, et. al. Standards Track [Page 31]
RFC 3261 SIP: Session Initiation Protocol June 2002 Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once. When comparing header fields, field names are always case- insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example, Contact: <sip:[email protected]>;expires=3600 is equivalent to CONTACT: <sip:[email protected]>;ExPiReS=3600 and Content-Disposition: session;handling=optional is equivalent to content-disposition: Session;HANDLING=OPTIONAL The following two header fields are not equivalent: Warning: 370 devnull "Choose a bigger pipe" Warning: 370 devnull "CHOOSE A BIGGER PIPE" 7.3.2 Header Field Classification Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored. Section 20 defines the classification of each header field. 7.3.3 Compact Form SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages would otherwise become too large to be carried on the transport available to it (exceeding the maximum transmission unit (MTU) when using UDP, for example). These compact forms are defined in Section 20. A compact form MAY be substituted for the longer form of a header field name at any time without changing the semantics of the message. A header Rosenberg, et. al. Standards Track [Page 32]
RFC 3261 SIP: Session Initiation Protocol June 2002 field name MAY appear in both long and short forms within the same message. Implementations MUST accept both the long and short forms of each header name. 7.4 Bodies Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method. For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body. 7.4.1 Message Body Type The Internet media type of the message body MUST be given by the Content-Type header field. If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. If applicable, the character set of the message body is indicated as part of the Content-Type header-field value. The "multipart" MIME type defined in RFC 2046 [11] MAY be used within the body of the message. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart. SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "UTF-8". 7.4.2 Message Body Length The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the necessary contents of this header field in detail. The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.) Rosenberg, et. al. Standards Track [Page 33]
RFC 3261 SIP: Session Initiation Protocol June 20027.5 Framing SIP Messages Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such datagram carries one request or response. See Section 18 on constraints on usage of unreliable transports. Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1]. The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports. 8 General User Agent Behavior A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A UAS is capable of receiving a request and generating a response based on user input, external stimulus, the result of a program execution, or some other mechanism. When a UAC sends a request, the request passes through some number of proxy servers, which forward the request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC. UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE. In this section, we discuss the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog. This includes, of course, the requests which themselves establish a dialog. Security procedures for requests and responses outside of a dialog are described in Section 26. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features are also supported through encryption of bodies using S/MIME. Rosenberg, et. al. Standards Track [Page 34]
RFC 3261 SIP: Session Initiation Protocol June 20028.1 UAC Behavior This section covers UAC behavior outside of a dialog. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. These header fields are in addition to the mandatory request line, which contains the method, Request-URI, and SIP version. Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11). 8.1.1.1 Request-URI The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit). In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI. Rosenberg, et. al. Standards Track [Page 35]
RFC 3261 SIP: Session Initiation Protocol June 20028.1.1.2 To The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Frequently, the user will not enter a complete URI, but rather a string of digits or letters (for example, "bob"). It is at the discretion of the UA to choose how to interpret this input. Using the string to form the user part of a SIP URI implies that the UA wishes the name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI (for instance, sip:[email protected]). Using the string to form the user part of a SIPS URI implies that the UA wishes to communicate securely, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like "speed dial" that require interpretation of the user part in the home domain. The tel URL may be used when the UA does not wish to specify the domain that should interpret a telephone number that has been input by the user. Rather, each domain through which the request passes would be given that opportunity. As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. If they enter "411" (this is the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not the user's home domain. In this case, tel:411 would be the right choice. A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present. For further information on the To header field, see Section 20.39. The following is an example of a valid To header field: To: Carol <sip:[email protected]> Rosenberg, et. al. Standards Track [Page 36]
RFC 3261 SIP: Session Initiation Protocol June 20028.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. The From header field allows for a display name. A UAC SHOULD use the display name "Anonymous", along with a syntactically correct, but otherwise meaningless URI (like sip:[email protected]), if the identity of the client is to remain hidden. Usually, the value that populates the From header field in requests generated by a particular UA is pre-provisioned by the user or by the administrators of the user's local domain. If a particular UA is used by multiple users, it might have switchable profiles that include a URI corresponding to the identity of the profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain that they are who their From header field claims they are (see Section 22 for more on authentication). The From field MUST contain a new "tag" parameter, chosen by the UAC. See Section 19.3 for details on choosing a tag. For further information on the From header field, see Section 20.20. Examples: From: "Bob" <sips:[email protected]> ;tag=a48s From: sip:[email protected];tag=887s From: Anonymous <sip:[email protected]>;tag=hyh8 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. Note that when requests are retried after certain Rosenberg, et. al. Standards Track [Page 37]
RFC 3261 SIP: Session Initiation Protocol June 2002 failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form "[email protected]". Call-IDs are case-sensitive and are simply compared byte-by-byte. Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions. No provisioning or human interface is required for the selection of the Call-ID header field value for a request. For further information on the Call-ID header field, see Section20.8. Example: Call-ID: [email protected] 8.1.1.5 CSeq The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values. Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog. Example: CSeq: 4711 INVITE Rosenberg, et. al. Standards Track [Page 38]
RFC 3261 SIP: Session Initiation Protocol June 20028.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA. 8.1.1.7 Via The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]). When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server. The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543. The branch ID inserted by an element compliant with this specification MUST always begin with the characters "z9hG4bK". These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can determine that the branch ID was constructed in the fashion described by this Rosenberg, et. al. Standards Track [Page 39]
RFC 3261 SIP: Session Initiation Protocol June 2002 specification (that is, globally unique). Beyond this requirement, the precise format of the branch token is implementation-defined. The Via header maddr, ttl, and sent-by components will be set when the request is processed by the transport layer (Section 18). Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3. 8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. For further information on the Contact header field, see Section20.10. 8.1.1.9 Supported and Require If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. The option tags listed MUST only refer to extensions defined in standards-track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor-defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header field in a request, since they too are often used to document vendor-defined extensions. If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it MUST insert a Require header field into the request listing the option tag for that extension. If the UAC wishes to apply an extension to the request and insist that any proxies that are Rosenberg, et. al. Standards Track [Page 40]
RFC 3261 SIP: Session Initiation Protocol June 2002 traversed understand that extension, it MUST insert a Proxy-Require header field into the request listing the option tag for that extension. As with the Supported header field, the option tags in the Require and Proxy-Require header fields MUST only refer to extensions defined in standards-track RFCs. 8.1.1.10 Additional Message Components After a new request has been created, and the header fields described above have been properly constructed, any additional optional header fields are added, as are any header fields specific to the method. SIP requests MAY contain a MIME-encoded message-body. Regardless of the type of body that a request contains, certain header fields must be formulated to characterize the contents of the body. For further information on these header fields, see Sections 20.11 through 20.15. 8.1.2 Sending the Request The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request. Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI. Local policy MAY specify an alternate set of destinations to attempt. If the Request-URI contains a SIPS URI, any alternate destinations MUST be contacted with TLS. Beyond that, there are no restrictions on the alternate destinations if the request contains no Route header field. This provides a simple alternative to a pre-existing route set as a way to specify an outbound proxy. However, that approach for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing route set with a single URI SHOULD be used instead. If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC2543). In particular, a UAC configured with an outbound proxy SHOULD Rosenberg, et. al. Standards Track [Page 41]
RFC 3261 SIP: Session Initiation Protocol June 2002 attempt to send the request to the location indicated in the first Route header field value instead of adopting the policy of sending all messages to the outbound proxy. This ensures that outbound proxies that do not add Record-Route header field values will drop out of the path of subsequent requests. It allows endpoints that cannot resolve the first Route URI to delegate that task to an outbound proxy. The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field is set to whatever transport was determined for the target server. 8.1.3 Processing Responses Responses are first processed by the transport layer and then passed up to the transaction layer. The transaction layer performs its processing and then passes the response up to the TU. The majority of response processing in the TU is method specific. However, there are some general behaviors independent of the method. 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. 8.1.3.2 Unrecognized Responses A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code. A UAC MUST treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). A UAC MUST be able to process 100 and 183 responses. Rosenberg, et. al. Standards Track [Page 42]
RFC 3261 SIP: Session Initiation Protocol June 20028.1.3.3 Vias If more than one Via header field value is present in a response, the UAC SHOULD discard the message. The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted. 8.1.3.4 Processing 3xx Responses Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. This process is similar to that of a proxy recursing on a 3xx class response as detailed in Sections 16.5 and 16.6. A client starts with an initial target set containing exactly one URI, the Request-URI of the original request. If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set. Subject to the restrictions in this specification, a client can choose which Contact URIs it places into the target set. As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once. If the original request had a SIPS URI in the Request- URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI. Any new request may receive 3xx responses themselves containing the original URI as a contact. Two locations can be configured to redirect to each other. Placing any given URI in the target set only once prevents infinite redirection loops. As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the "q" parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of decreasing q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value. If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed. Rosenberg, et. al. Standards Track [Page 43]
RFC 3261 SIP: Session Initiation Protocol June 2002 Failures SHOULD be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user. Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not be considered failures. When a failure for a particular contact address is received, the client SHOULD try the next contact address. This will involve creating a new client transaction to deliver a new request. In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the "method-param" and "header" URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the "header" parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section19.1.5. Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request. As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address. For example, if a contact address is returned with the following value: sip:[email protected]?Subject=foo&Call-Info=<http://www.foo.com> Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values. It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example. Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7. Rosenberg, et. al. Standards Track [Page 44]
RFC 3261 SIP: Session Initiation Protocol June 2002 In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request. In some instances, Contact header field values may be cached at UAC temporarily or permanently depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 21.3.3. 8.1.3.5 Processing 4xx Responses Certain 4xx response codes require specific UA processing, independent of the method. If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. If a 413 (Request Entity Too Large) response is received (Section21.4.11), the request contained a body that was longer than the UAS was willing to accept. If possible, the UAC SHOULD retry the request, either omitting the body or using one of a smaller length. If a 415 (Unsupported Media Type) response is received (Section21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. If a 416 (Unsupported URI Scheme) response is received (Section21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI. If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or Proxy-Require header field listing an option-tag for a feature not supported by a proxy or UAS. The UAC SHOULD retry the request, this time omitting any extensions listed in the Unsupported header field in the response. In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. Rosenberg, et. al. Standards Track [Page 45]
RFC 3261 SIP: Session Initiation Protocol June 2002 With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. 8.2 UAS Behavior When a request outside of a dialog is processed by a UAS, there is a set of processing rules that are followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or outside of a dialog. Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed. UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). 8.2.1 Method Inspection Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The UAS MUST also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header field MUST list the set of methods supported by the UAS generating the message. The Allow header field is presented in Section 20.5. If the method is one supported by the server, processing continues. 8.2.2 Header Inspection If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests. 8.2.2.1 To and Request-URI The To header field identifies the original recipient of the request designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To Rosenberg, et. al. Standards Track [Page 46]
RFC 3261 SIP: Session Initiation Protocol June 2002 header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission. However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs. 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. 8.2.2.3 Require Assuming the UAS decides that it is the proper element to process the request, it examines the Require header field, if present. The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects the UAS to support in order to process the request properly. Its format is described in Section20.32. If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request. Rosenberg, et. al. Standards Track [Page 47]
RFC 3261 SIP: Session Initiation Protocol June 2002 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they are present in these requests. An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request. Example: UAC->UAS: INVITE sip:[email protected] SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. 8.2.3 Content Processing Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood by the UAS, the response MUST contain an Accept-Encoding header field listing the encodings understood by the UAS. If the request contained content with languages not understood by the UAS, the response MUST contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these checks, body handling depends on the method and type. For further information on the processing of content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15. Rosenberg, et. al. Standards Track [Page 48]
RFC 3261 SIP: Session Initiation Protocol June 20028.2.4 Applying Extensions A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response cannot be generated without support of a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability. Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards- track RFCs. 8.2.5 Processing the Request Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific. Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request. 8.2.6 Generating the Response When a UAS wishes to construct a response to a request, it follows the general procedures detailed in the following subsections. Additional behaviors specific to the response code in question, which are not detailed in this section, may also be required. Once all procedures associated with the creation of a response have been completed, the UAS hands the response back to the server transaction from which it received the request. 8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. Rosenberg, et. al. Standards Track [Page 49]
RFC 3261 SIP: Session Initiation Protocol June 2002 When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending of the response and receipt of the request, measured in seconds. 8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3. 8.2.7 Stateless UAS Behavior A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer. The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of Rosenberg, et. al. Standards Track [Page 50]
RFC 3261 SIP: Session Initiation Protocol June 2002 transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5. The most important behaviors of a stateless UAS are the following: o A stateless UAS MUST NOT send provisional (1xx) responses. o A stateless UAS MUST NOT retransmit responses. o A stateless UAS MUST ignore ACK requests. o A stateless UAS MUST ignore CANCEL requests. o To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. For information on tag construction see Section 19.3. In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate in either a stateful or stateless mode for each new request. 8.3 Redirect Servers In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection. Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability. A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found. A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the Rosenberg, et. al. Standards Track [Page 51]
RFC 3261 SIP: Session Initiation Protocol June 2002 location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers. When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An "expires" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data. The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa. However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404. If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops. Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as "The number you have dialed has been changed." A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI. The "expires" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600. Rosenberg, et. al. Standards Track [Page 52]
RFC 3261 SIP: Session Initiation Protocol June 2002 This provides a modest level of backwards compatibility with RFC2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600. Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question. 9 Canceling a Request The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL. The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). CANCEL requests can be constructed and sent by both proxies and user agent clients. Section 15 discusses under what conditions a UAC would CANCEL an INVITE request, and Section 16.10 discusses proxy usage of CANCEL. A stateful proxy responds to a CANCEL, rather than simply forwarding a response it would receive from a downstream element. For that reason, CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop. 9.1 Client Behavior A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition. Rosenberg, et. al. Standards Track [Page 53]
RFC 3261 SIP: Session Initiation Protocol June 2002 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values. This is needed so that stateless proxies are able to route CANCEL requests properly. The CANCEL request MUST NOT contain any Require or Proxy-Require header fields. Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the "original request"). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. If the original request has generated a final response, the CANCEL SHOULD NOT be sent, as it is an effective no-op, since CANCEL has no effect on requests that have already generated a final response. When the client decides to send the CANCEL, it creates a client transaction for the CANCEL and passes it the CANCEL request along with the destination address, port, and transport. The destination address, port, and transport for the CANCEL MUST be identical to those used to send the original request. If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request. Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is Rosenberg, et. al. Standards Track [Page 54]
RFC 3261 SIP: Session Initiation Protocol June 2002 defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. 9.2 Server Behavior The CANCEL method requests that the TU at the server side cancel a pending transaction. The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction matching procedures of Section 17.2.3. The matching transaction is the one to be cancelled. The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. See Section 16.10 for proxy treatment of CANCEL. A UAS first processes the CANCEL request according to the general UAS processing described in Section 8.2. However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be challenged by the server in order to get proper credentials in an Authorization header field. Note also that CANCEL requests do not contain a Require header field. If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request. If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request. If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). A CANCEL request has no impact on the processing of transactions with any other method defined in this specification. Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is passed to the server transaction for transmission. Rosenberg, et. al. Standards Track [Page 55]
RFC 3261 SIP: Session Initiation Protocol June 200210 Registrations10.1 Overview SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sip:[email protected], for example, to one or more URIs that are somehow "closer" to the desired user, sip:[email protected], for example. Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing. Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would be routed to that domain. In most cases, this means that the domain of the registration will need to match the domain in the URI of the address-of-record. There are many ways by which the contents of the location service can be established. One way is administratively. In the above example, Bob is known to be a member of the engineering department through access to a corporate database. However, SIP provides a mechanism for a UA to create a binding explicitly. This mechanism is known as registration. Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests. This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. An illustration of the overall registration process is given in Figure 2. Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for purposes of Rosenberg, et. al. Standards Track [Page 56]
RFC 3261 SIP: Session Initiation Protocol June 2002 clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements. SIP does not mandate a particular mechanism for implementing the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. A registrar MAY be co-located with a particular SIP proxy server for the same domain. 10.2 Constructing the REGISTER Request REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of- record. Except as noted, the construction of the REGISTER request and the behavior of clients sending a REGISTER request is identical to the general UAC behavior described in Section 8.1 and Section 17.1. A REGISTER request does not establish a dialog. A UAC MAY include a Route header field in a REGISTER request based on a pre-existing route set as described in Section 8.1. The Record-Route header field has no meaning in REGISTER requests or responses, and MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a REGISTER request. The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included: Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, "sip:chicago.com"). The "userinfo" and "@" components of the SIP URI MUST NOT be present. To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI. Rosenberg, et. al. Standards Track [Page 57]
RFC 3261 SIP: Session Initiation Protocol June 2002 From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third- party registration. Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order. CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID. Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings. UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. Rosenberg, et. al. Standards Track [Page 58]
RFC 3261 SIP: Session Initiation Protocol June 2002 bob +----+ | UA | | | +----+ | |3)INVITE | [email protected] chicago.com +--------+ V +---------+ 2)Store|Location|4)Query +-----+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +---------+ +--------+=======>+-----+ A 5)Resp | | | | | 1)REGISTER| | | | +----+ | | UA |<-------------------------------+ cube2214a| | 6)INVITE +----+ [email protected] carol Figure 2: REGISTER example The following Contact header parameters have a special meaning in REGISTER requests: action: The "action" parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the "action" parameter. expires: The "expires" parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600. 10.2.1 Adding Bindings The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded. The address-of-record is included in the To header field of the REGISTER request. Rosenberg, et. al. Standards Track [Page 59]
RFC 3261 SIP: Session Initiation Protocol June 2002 The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, "sip:[email protected]"), but they MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record, for example. For example, Carol, with address-of-record "sip:[email protected]", would register with the SIP registrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com domain to route requests for Carol's address-of-record to her SIP endpoint. Once a client has established bindings at a registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar. If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses. 10.2.1.1 Setting the Expiration Interval of Contact Addresses When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.) There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an "expires" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter. Rosenberg, et. al. Standards Track [Page 60]
RFC 3261 SIP: Session Initiation Protocol June 2002 If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose. 10.2.1.2 Preferences among Contact Addresses If more than one Contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these Contact header field values with the address-of-record present in the To field. This list can be prioritized with the "q" parameter in the Contact header field. The "q" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. Section 16.6 describes how a proxy server uses this preference indication. 10.2.2 Removing Bindings Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar as described in Section10.2.1
Sours: https://tools.ietf.org/html/rfc3261
anynode 23 - SIP-Header auslesen und setzen

Tipsy Collab

What The F-Heck Are Route and Record-Route SIP Headers??

Everyone is familiar with the basic SIP headers like CSeq and Call-ID (I’m not gonna mention From and To :)). Some might even know Remote-Party-ID or Contact headers. What I’ve noticed throughout the years though, is that not many are familiar with the Record-Route and Route SIP headers. Not sure why as they’re pretty useful to know. Let’s have a look!

The Concept

A picture is worth a thousand words or whatever the saying goes so I’ll explain the concept on the most basic call flow diagram. It involves me (Maciej) communicating with tipsycollab.com via 2 proxies – P1 and P2.

Route and Record-Route SIP Headers

Just in case you’re not familiar with the Via header, it specifies the path for response messages to the Invite request. They’re added in the request by each proxy along the path and by the UAC (User Agent Client – in this case, Maciej).
As the response travels back, the corresponding Via header is removed at each hop.

Now since we got the Via headers out of the way, let’s have a look at the main topic of this article.
Record-Route headers are added to the request only by proxies that wish to remain in the call signaling path. In the example above, only P2 shows that interest.
What’s important to note is that the Record-Route headers are not modified in the reply.

When Maciej receives the reply (200 OK) containing the Record-Route headers, it will reverse their order and change it to Route headers on the next request (ACK).
Yes, you’re right – there is nothing to reverse here as there is only one Record-Route header above, the real-world example that follows has more so keep an eye on the reversed order.
In essence, the Route headers specify the path a request should take.
It’s going directly from Maciej to P2, bypassing P1.

The Real World

How does it look like in the real world?
Let’s say P2 in the diagram above is Expressway-E while tipsycollab.com is webex.com. There will be slight differences comparing to the diagram as Expressway is acting as a B2BUA, not a Proxy in this scenario.
Showing only relevant parts of the messages as a lot is going on, especially in the Via headers, on Expressway.

As you can see, the Invite contains Expressway’s public IP (20.20.20.20) and external NIC IP (192.168.20.20) in the Record-Route SIP headers thus making sure it remains in the call path.

When the 200 OK comes in, in addition to the above Record-Route headers, three more are added making sure each of the Webex servers remains in the call path.

The Record-Route headers from the 200 OK above are then reversed and modified to Route headers thus making sure the next request (ACK) is following the expected path.
Well, I don’t see the two Expressway IPs you might say – there are only 3 Route headers instead of 5. Yes, indeed, these are removed as the ACK message leaves Expressway. You would see them though on the internal processing via the B2BUA component of Expressway.

Summary

That’s it, folks.
I’ve tried to remove all the unnecessary bits and pieces to really make you understand the Record-Route and Route SIP headers.
I know however that there are some items I touched upon along the way that could have their own article.

Curious to know your opinion, was this useful and clear enough?
Get in touch here or leave a comment below.

Sours: https://tipsycollab.com/sip-headers/

You will also like:

This feature allows the Oracle Communications Session Border Controller to include SIP methods in routing decisions. If you want to use this feature, you set a list of one or more SIP methods in the local policy attributes. These are the SIP methods you can enter in the list: INVITE, REGISTER, PRACK, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, MESSAGE, and PUBLISH.

After the Oracle Communications Session Border Controller performs a local policy look-up for SIP, it then searches for local policy attributes that have this methods list configured. If it finds a a set of policy attributes that matches a method that matches the traffic it is routing, the Oracle Communications Session Border Controller uses that set of policy attributes. This means that the Oracle Communications Session Border Controller considers first any policy attributes with methods configured before it considers those that do not have methods. In the absence of any policy attributes with methods, the Oracle Communications Session Border Controller uses the remaining ones for matching.

In cases where it finds neither matching policy attributes with methods or matching policy attributes without them, the Oracle Communications Session Border Controller either rejects the calls with a 404 No Routes Found (if the request calls for a response) or drops the call.

You configure local policy matching with SIP methods in the local policy attributes parameter calls methods. This parameter is a list that takes either one or multiple values. If you want to enter multiple values, you put them in the same command line entry, enclosed in quotation marks and separated by spaces.

To configure SIP methods for local policy matching:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminalORACLE(configure)#
  2. Type session-router and press Enter.
    ORACLE(configure)# session-routerORACLE(session-router)#
  3. Type local-policy and press Enter. If you are adding this feature to a pre-existing local policy configuration, you will need to select and edit your local policy.
    ORACLE(session-router)# local-policyORACLE(local-policy)#
  4. Type policy-attributes and press Enter. If you are adding this feature to a pre-existing local policy configuration, you will need to select and edit your local policy.
    ORACLE(local-policy))# policy-attributesORACLE(policy-attributes)#
  5. methods—Enter the SIP methods you want to use for matching this set of policy attributes. Your list can include: INVITE, REGISTER, PRACK, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, MESSAGE, and PUBLISH.

    By default, this parameter is empty—meaning that SIP methods will not be taken into consideration for routing based on this set of policy attributes.

    If you want to enter more than one method, you entry will resemble the following example.

    ACMEPACKET(local-policy-attributes)# methods "PRACK INFO REFER"
  6. Save and activate your configuration.
Sours: https://docs.oracle.com/cd/E95618_01/html/sbc_scz810_acliconfiguration/GUID-931B056A-CDAE-43D4-9407-2E5BA99573D1.htm


632 633 634 635 636