4
SIP Request Messages
This chapter covers the types of SIP requests called methods. Six are described in the SIP specification document RFC 3261 [1]. Eight more methods are described in separate RFC documents. After discussing the methods, this chapter concludes with a discussion of SIP URLs and URIs, tags, and message bodies.
4.1 Methods
SIP requests or methods are considered “verbs” in the protocol, since they request a specific action to be taken by another user agent or server. The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six methods
in SIP. The REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, UPDATE, INFO, and
PRACK methods are described in separate RFCs.
A user agent (UA) receiving a method it does not support replies with a 501 response. Method names are case sensitive and conventionally use all uppercase for visual clarity to distinguish them from header fields, which
use both upper and lower case. Note that a proxy does not need to understand a request method in order to forward the request. A proxy treats an unknown method as if it were an OPTIONS; that is, it forwards the request to the destination if it can. This allows new features and methods useful for user agents to be introduced without requiring support from proxies that may be in the middle. UAs should indicate which methods they support in an Allow header field in requests and responses.
4.1.1INVITE
The INVITE method is used to establish media sessions between user agents. In telephony, it is similar to a Setup message in ISDN or an initial address message (IAM) in ISUP. (PSTN protocols are briefly introduced in Section 11.1.)
73
74 |
SIP: Understanding the Session Initiation Protocol |
Responses to INVITEs are always acknowledged with the ACK method described in Section 4.1.4. Examples of the use of the INVITE method are described in Chapter 2.
An INVITE usually has a message body containing the media information of the caller. The message body can also contain other session information, such as a resource list. If an INVITE does not contain media information, the ACK contains the media information of the UAC. An example of this call flow is shown in Figure 4.1. If the media information contained in the ACK is not acceptable, then the called party must send a BYE to cancel the session—a CANCEL cannot be sent because the session is already established. A media session is considered established when the INVITE, 200 OK, and ACK messages have been exchanged between the UAC and the UAS. A successful INVITE request establishes a dialog between the two user agents, which continues until a BYE is sent by either party to end the session, as described in Section 4.1.3.
A UAC that originates an INVITE to establish a dialog creates a globally unique Call-ID that is used for the duration of the call. A CSeq count is initialized (which need not be set to 1, but must be an integer) and incremented for each new request for the same Call-ID. The To and From headers are populated with the remote and local addresses. A From tag is included in the INVITE, and the UAS includes a To tag in any responses, as described in Section 4.3. A To tag in a 200 OK response to an INVITE is used in the To header field of the ACK and all future requests within the dialog. The combination of the To tag, From tag, and Call-ID is the unique identifier for the dialog.
An INVITE sent for an existing dialog references the same Call-ID as the original INVITE and contains the same To and From tags. Sometimes called a re-INVITE, the request is used to change the session characteristics or refresh the state of the dialog. The CSeq command sequence number is incremented so
Figure 4.1 INVITE without an SDP offer.
SIP Request Messages |
75 |
that a UAS can distinguish the re-INVITE from a retransmission of the original
INVITE.
If a re-INVITE is refused or fails in any way, the session continues as if the INVITE had never been sent. A re-INVITE must not be sent by a UAC until a final response to the initial INVITE has been received—instead, an UPDATE request can be sent, as described in Section 4.1.14. There is an additional case where two UAs simultaneously send re-INVITEs to each other. This is handled in the same way with a Retry-After header. This condition is called glare in telephony (see Figure 5.3) and occurs when both ends of a trunk group seize the same trunk at the same time.
An Expires header in an INVITE indicates to the UAS how long the call request is valid. For example, the UAS could leave an unanswered INVITE request displayed on a screen for the duration specified in the Expires header. Once a session is established, the Expires header has no meaning—the expiration of the time does not terminate the media session. Instead, a Session-Expires header can be used to place a time limit on an established session without a re-INVITE or UPDATE refresh.
An example INVITE request with a SDP message body is shown here:
INVITE sip:411@salzburg.at;user=phone SIP/2.0
Via: SIP/2.0/UDP salzburg.edu.at:5060;branch=z9hG4bK1d32hr4 Max-Forwards:70
To: <sip:411@salzburg.at;user=phone>
From: Christian Doppler <sip:c.doppler@salzburg.edu.at> ;tag=817234
Call-ID: 12-45-A5-46-F5-43-32-F3-C2 CSeq: 1 INVITE
Subject: Train Timetables
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY
Contact: sip:c.doppler@salzburg.edu.at Content-Type: application/sdp Content-Length: 195
v=0
o=doppler 2890842326 2890844532 IN IP4 salzburg.edu.at s=-
c=IN IP4 50.61.72.83 t=0 0
m=audio 49172 RTP/AVP 97 98 0 a=rtpmap:97 iLBC/8000 a=rtpmap:98 SPEEX/8000 a=rtpmap:0 PCMU/8000
In addition to the required headers, this request contains the optional Subject and Allow header fields. Note that this Request-URI contains a phone number. Phone number support in SIP URIs is described in Section 4.2.
The mandatory and header fields in an INVITE request are shown in Table
4.1.
76 |
SIP: Understanding the Session Initiation Protocol |
Table 4.1
Mandatory Header Fields in an INVITE
Via
To
From
Call-ID
CSeq
Contact
Max-Forwards
4.1.2REGISTER
The REGISTER method is used by a UA to notify a SIP network of its current Contact URI (IP address) and the URI that should have requests routed to this Contact. As mentioned in Section 3.5.3, SIP registration bears some similarity to cell phone registration on initialization. Registration is not required to enable a user agent to use a proxy server for outgoing calls. It is necessary, however, for a user agent to register to receive incoming calls from proxies that serve that domain, unless some non-SIP mechanism is used by the location service to populate the SIP URIs and Contacts of end points. A REGISTER request may contain a message body, although its use is not defined in the standard. Depending on the use of the Contact and Expires headers in the REGISTER request, the registrar server will take different actions. Examples of this are shown in Table 4.2. If no expires parameter or Expires header is present, a SIP URI will expire in 1 hour. The presence of an Expires header sets the expiration of Contacts with no expires parameter. If an expires parameter is present, it sets the expiration time for that Contact only. Non-SIP URIs have no default expiration time.
The CSeq is incremented for a REGISTER request. The use of the RequestURI, To, From, and Call-ID headers in a REGISTER request is slightly different
Table 4.2
Example Registration Contact URIs
Request Headers |
Registrar Action |
|
Contact: * |
Cancel all registrations. |
|
Expires: 0 |
||
|
||
Contact: sip:galvani@bologna.edu.it |
Add Contact to current registrations; |
|
;expires=1800 |
registration expires in 30 minutes. |
|
Contact: sip:sgalvani@192.34.3.1 |
Add Contact to current registrations; |
|
Expires: 1800 |
registration expires in 30 minutes. |
|
Contact: mailto:galvani@bologna.edu.it |
Add email URL, which doesn’t expire. |
|
;q=0.1 |
||
|
||
No Contact header present |
Return all current registrations in |
|
response. |
||
|
SIP Request Messages |
77 |
than for other requests. The Request-URI contains only the domain of the registrar server with no user portion. The REGISTER request may be forwarded or proxied until it reaches the authoritative registrar server for the specified domain. The To header contains the SIP URI of the AOR (address of record) of the user agent that is being registered. The From contains the SIP URI of the sender of the request, usually the same as the To header. It is recommended that the same Call-ID be used for all registrations by a user agent.
A user agent sending a REGISTER request may receive a 3xx redirection or 4xx failure response containing a Contact header of the location to which registrations should be sent.
A third-party registration occurs when the party sending the registration request is not the party that is being registered. In this case, the From header will contain the URI of the party submitting the registration on behalf of the party identified in the To header. Chapter 2 contains an example of a first-party registration. An example third-party registration request for the user Euclid is shown here:
REGISTER sip:registrar.athens.gr SIP/2.0
Via: SIP/2.0/UDP 201.202.203.204:5060;branch=z9hG4bK313
Max-Forwards:70
To: sip:euclid@athens.gr
From: <sip:secretary@academy.athens.gr>;tag=543131
Call-ID: 48erl8132409wqer
CSeq: 1 REGISTER
Contact: sip:euclid@parthenon.athens.gr
Contact: mailto:euclid@geometry.org
Content-Length: 0
In some cases, the Contact URI provided by a UA in a registration may not be routable. For example, if the UA is behind a NAT, or if a firewall is configured to block incoming requests from arbitrary hosts. If this Contact URI is used outside a SIP dialog (for example, in sending a REFER or performing attended transfer), then call control operations might fail. An extension mechanism has been developed in which a UA can request from a registrar a so-called Globally Routable User Agent URI or GRUU [2]. This URI can be used in Contact header fields and other places the device wants to be directly reachable. A UA includes
a Supported:gruu header field in a REGISTER request and a sip.instance feature
tag, and if the registrar supports the mechanism, a GRUU will be returned in the 200 OK to the register in the pub-gruu and temp-gruu Contact header field parameters. The temp-gruu changes each time a registration is refreshed, while the pub-gruu is valid as long as the registration is refreshed. An example Contact header field containing a GRUU is shown here:
Contact: <sip:euclid@201.202.203.204> ;pub-gruu=”sip:euclid@athens.gr;gr=urn:uuid:00a0dc91e6bdf6” ;temp-gruu=”sip:k20flasdf2da@athens.gr;gr”
78 |
SIP: Understanding the Session Initiation Protocol |
;+sip.instance=”<urn:uuid:00a0dc91e6bdf6>”
;expires=1800
The mandatory headers in a REGISTER request are shown in Table 4.3.
4.1.3BYE
The BYE method is used to terminate an established media session. In telephony, it is similar to a release message. A session is considered established if an INVITE has received a success class response (2xx) or an ACK has been sent. A BYE is sent only by UAs participating in the session, never by proxies or other third parties. It is an end-to-end method, so responses are only generated by the other UA. A
UA responds with a 481 Dialog/Transaction Does Not Exist to a BYE for an
unknown dialog.
A BYE cannot be used to cancel pending INVITEs because it will not be forked like an INVITE and may not reach the same set of UAs as the INVITE. An example BYE request looks like the following:
BYE sip:info@hypotenuse.org SIP/2.0
Via: SIP/2.0/TCP port443.hotmail.com:54212;branch=z9hG4bK312bc Max-Forwards:70
To: <sip:info@hypotenuse.org>;tag=63124 From: <sip:pythag42@hotmail.com>;tag=9341123 Call-ID: 34283291273
CSeq: 47 BYE Content-Length: 0
The mandatory headers in a BYE request are shown in Table 4.4.
4.1.4ACK
The ACK method is used to acknowledge final responses to INVITE requests. Final responses to all other requests are never acknowledged. Final responses are defined as 2xx, 3xx, 4xx, 5xx, or 6xx class responses. The CSeq number is never incremented for an ACK, but the CSeq method is changed to ACK. This is so that a UAS can match the CSeq number of the ACK with the number of the correspond-
ing INVITE.
Table 4.3
Mandatory Header Fields in a REGISTER
Via
To
From
Call-ID
CSeq
Max-Forwards
SIP Request Messages |
79 |
Table 4.4
Mandatory Header Fields in a BYE
Via
To
From
Call-ID
CSeq
Max-Forwards
An ACK may contain an application/sdp message body. This is permitted if the initial INVITE did not contain a SDP message body. If the INVITE contained an SDP offer message body, the ACK may not contain an SDP message body. The ACK may not be used to modify a media description that has already been sent in the initial INVITE; a re-INVITE or UPDATE must be used for this purpose. SDP in an ACK is used in some interworking scenarios with other protocols where the media characteristics may not be known when the initial INVITE is generated and sent.
For 2xx responses, the ACK is end-to-end, but for all other final responses it is done on a hop-by-hop basis when stateful proxies are involved. As a result, a proxy will generate an ACK for a 3xx, 4xx, 5xx, or 6xx response to an INVITE, as well as forwarding the response. The end-to-end nature of ACKs to 2xx responses allows a message body to be transported. An ACK generated in a hop-by-hop acknowledgment will contain just a single Via header with the address of the proxy server generating the ACK. The difference between hop-by-hop acknowledgments and response end-to-end acknowledgments is shown in the message fragments of Figure 4.2.
A hop-by-hop ACK reuses the same branch ID as the INVITE since it is considered part of the same transaction. An end-to-end ACK uses a different branch ID as it is considered a new transaction.
A stateful proxy receiving an ACK message must determine whether or not the ACK should be forwarded downstream to another proxy or user agent. That is, is the ACK a hop-by-hop ACK or an end-to-end ACK? This is done by comparing the branch ID for a match pending transaction branch IDs. If there is not an exact match, the ACK is proxied toward the UAS. Otherwise, the ACK is for this hop and is not forwarded by the proxy. Here is an example ACK containing SDP:
ACK sip:laplace@mathematica.org SIP/2.0
Via: SIP/2.0/TCP 128.5.2.1:5060;branch=z9hG4bK1834 Max-Forwards:70
To: Marquis de Laplace <sip:laplace@mathematica.org> ;tag=90210
From: Nathaniel Bowditch <sip:n.bowditch@salem.ma.us> ;tag=887865
Call-ID: 152-45-32-N-32-23-47-W
80 |
SIP: Understanding the Session Initiation Protocol |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 4.2 End-to-end versus hop-by-hop acknowledgments.
CSeq: 3 ACK
Content-Type: application/sdp
Content-Length: 172
v=0
o=bowditch 2590844326 2590944532 IN IP4 salem.ma.us s=Bearing
c=IN IP4 salem.ma.us t=0 0
m=audio 32852 RTP/AVP 96 0 a=rtpmap:96 SPEEX/8000 a=rtpmap:0 PCMU/8000
The mandatory and optional headers in an ACK message are shown in Table
4.5.
Table 4.5
Mandatory Header Fields in an ACK
Via
To
From
Call-ID
CSeq
Max-Forwards