96 |
SIP: Understanding the Session Initiation Protocol |
session in a completely analogous way that SIP is commonly used to establish a media session. An INVITE could be used to establish the session with a SDP body that describes the instant message protocol to be used directly between the two users. For example, Message Sessions Relay Protocol (MSRP), covered in Section 8.5.5, can be used for this.
An example MESSAGE request is shown here:
MESSAGE sip:editor@rcs.org SIP/2.0
Via SIP/2.0/UDP lab.mendeleev.org:5060;branch=z9hG4bK3 Max-Forwards: 70
To: <editor@rcs.org>
From: “D. I. Mendeleev” <dmitry@mendeleev.org>;tag=1865 Call-ID: 93847197172049343
CSeq: 5634 MESSAGE
Subject: First Row
Contact: <sip:dmitry@lab.mendeleev.org> Content-Type: text/plain Content-Length: 7
H, He
Table 4.13 lists the mandatory header fields in a MESSAGE request.
4.1.12 INFO
The INFO [26] method is used by a UA to send call signaling information to another UA with which it has an established media session. The request is end- to-end and is never initiated by proxies. A proxy will always forward an INFO re- quest—it is up to the UAS to check to see if the dialog is valid. INFO requests for
unknown dialogs receive a 481 Transaction/Dialog Does Not Exist response.
An INFO method typically contains a message body. The contents may be signaling information, a midcall event, or some sort of stimulus. INFO has been proposed to carry certain PSTN midcall signaling information such as ISUP (ISDN User Part) USR messages.
The INFO method always increments the CSeq. An example INFO method
is:
Table 4.13
Mandatory Header Fields in a MESSAGE
To
Via
To
From
Call-ID
CSeq
Max-Forwards
SIP Request Messages |
97 |
INFO sip:poynting@mason.edu.uk SIP/2.0
Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk ;branch=z9hG4bK24555
Max-Forwards: 70
To: John Poynting <sip:nting@mason.edu.uk> ;tag=3432
From: J.C. Maxwell <sip:james.maxwell@kings.cambridge.edu.uk> ;tag=432485820183
Call-ID: e71facaa7f7c0a29276054fe4951a9b6 Content-Type: application/ISUP Content-Length: ...
(Binary message body not shown)
The base INFO specification does not have any mechanisms for negotiating which types of INFO bodies are acceptable. An extension [27] is being developed to add this capability. The extension defines packages for INFO usages, and a mechanism to discover and declare support for packages. The Recv-Info header field is included in requests and responses listing the INFO packages that the UA is willing to receive. The Info-Package header field is included in INFO requests indicating which package is being used.
The mandatory headers in an INFO request are shown in Table 4.14. Note that for backwards compatibility reasons, INFO without Info-Package will need to be accepted.
4.1.13PRACK
The PRACK [28] method is used to acknowledge receipt of reliably transported provisional responses (1xx). The reliability of 2xx, 3xx, 4xx, 5xx, and 6xx responses to INVITEs is achieved using the ACK method. However, in cases where a provisional response, such as 180 Ringing, is critical in determining the call state, it may be necessary for the receipt of a provisional response to be confirmed. The PRACK method applies to all provisional responses except the 100 Trying response, which is never reliably transported.
A PRACK is generated by a UAC when a provisional response has been received containing an RSeq reliable sequence number and a Supported: 100rel
Table 4.14
Mandatory Header Fields in an INFO
To
Via
To
From
Call-ID
CSeq
Max-Forwards
Info-Package
98 |
SIP: Understanding the Session Initiation Protocol |
header. The PRACK echoes the number in the RSeq and the CSeq of the response in a RAck header. The message flow is as shown in Figure 4.11. In this example, the UAC sends the 180 Ringing response reliably by including the RSeq header. When no PRACK is received from the UAC after the expiration of a timer (an “X” is used to represent a lost message), the response is retransmitted. The receipt of the PRACK confirms the delivery of the response and stops all further transmissions. The 200 OK response to the PRACK stops retransmissions of the PRACK request.
Reliable responses are retransmitted using the same exponential backoff mechanism used for final responses to an INVITE. The combination of Call-ID, CSeq number, and RAck number allows the UAC to match the PRACK to the provisional response it is acknowledging. As shown in Figure 4.11, the PRACK receives a 200 OK response, which can be distinguished from the 200 OK to the INVITE by the method contained in the CSeq header.
The PRACK method always increments the CSeq. A PRACK may contain a message body and may be used for offer/answer exchanges. An example exchange contains:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk ;branch=z9hG4bK452352;received=1.2.3.4
To: Descartes <sip:rene.descartes@metaphysics.org>;tag=12323 From: Newton <sip:newton@kings.cambridge.edu.uk>;tag=981
Figure 4.11 PRACK call flow example showing reliable provisional responses.
SIP Request Messages |
99 |
Call-ID: da6fa909f1c0188c539feb08d4496eb7
RSeq: 314
CSeq: 10 INVITE
Content-Length: 0
PRACK sip:rene.descartes@metaphysics.org SIP/2.0 Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk ;branch=z9hG4bKdtyw
Max-Forwards: 70
To: Descartes <sip:rene.descartes@metaphysics.org>;tag=12323 From: Newton <sip:newton@kings.cambridge.edu.uk>;tag=981 Call-ID: da6fa909f1c0188c539feb08d4496eb7
CSeq: 2 PRACK RAck: 314 10 INVITE Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk ;branch=z9hG4bKdtyw ;received=1.2.3.4
To: Descartes <sip:rene.descartes@metaphysics.org>;tag=12323 From: Newton <sip:newton@kings.cambridge.edu.uk>;tag=981 Call-ID: da6fa909f1c0188c539feb08d4496eb7
CSeq: 2 PRACK Content-Length: 0
The mandatory header fields in a PRACK request are shown in Table 4.15.
4.1.14 UPDATE
The UPDATE method [29] is used to modify the state of a session without changing the state of the dialog. A session is established in SIP using an INVITE request (see Section 4.1.1) in an offer/answer manner, described in Chapter 13. Typically, a session offer is made in the INVITE and an answer is made in a response to the INVITE. In an established session, a re-INVITE is used to update session parameters. However, neither party in a pending session (INVITE sent but no final response received) may re-INVITE—instead, the UPDATE method is used.
Possible uses of UPDATE include muting or placing on hold pending media streams, performing QoS, or other end-to-end attribute negotiation prior to session establishment.
Table 4.15
Mandatory Header Fields in a PRACK
To
Via
To
From
Call-ID
CSeq
Max-Forwards
RAck