SIP Request Messages
4.4 Message Bodies
Message bodies in SIP may contain various types of information. They may con-tain SDP information, which can be used to convey media information, QoS, or even security information.
The optional Content-Disposition header is used to indicate the intended use of the message body. If not present, the function is assumed to be session, which means that the body describes a media session. Besides session, the other defi ned function is render, which means that the message body should be pre-sented to the user or otherwise used or displayed. This could be used to pass a small JPEG image fi le or URI.
The format of the message body is indicated by the Content-Type header.
If a message contains a message body, the message must include a Content-Type
header. All UAs must support a Content-Type of application/sdp. The encod-ing scheme of the message body is indicated in the Content-Encoding header. If not specifi ed, the encoding is assumed to be text/plain. The specifi cation of a
Content-Encoding scheme allows the message body to be compressed.
The Content-Length header contains the number of octets in the message body. If there is no message body, the Content-Length header should still be included but with a value of 0. Because multiple SIP messages can be sent in a TCP stream, the Content-Length count is a reliable way to detect when one mes-sage ends and another begins. If a Content-Length is not present, the UAC must assume that the message body continues until the end of the UDP datagram, or until the TCP connection is closed, depending on the transport protocol.
Message bodies can have multiple parts if they are encoded using Multipart Internet Mail Extensions (MIME). Message bodies in SIP, however, should be small enough so that they do not exceed the UDP MTU of the network. Proxies may reject requests with large message bodies with a 413 Request Entity Too Large response, since processing large messages can load a server. Guidelines for SIP handling of message bodies is described in [31].
As mentioned in the previous section, SIP carries message bodies the same way that e-mails carry attachments. It is possible to carry multiple message bod-ies within a single SIP message. This is done using a multipart MIME body. The
Content-Type is listed as multipart/mime, and a separator is defi ned, which is used by the parser to separate the message. Any SIP request or response that can contain a message body may carry a multipart MIME body. An example is in SIP-T (see Section 11.2) in which an INVITE carries both a SDP message body (application/sdp) and an encapsulated ISUP message (application/isup). An example multipart MIME is:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac To: sip:[email protected]
From: <sip:[email protected]>;tag=2909034023
o=referree 2890844526 2890844526 IN IP4 referree.example s=Session SDP
Date: Thu, 21 Feb 2002 13:02:03 GMT Call-ID: 2203900ef0299349d9209f023a
—-*-boundary-*—-Between each body part is a string, in this example -*-boundary-*- which is defi ned in the Content-Type header fi eld.
SIP Request Messages 107
4.5 Conclusion
This chapter covered the six base methods in RFC 3261 plus the eight extension methods defi ned in other RFCs. In addition, SIP URIs, URLs, tags, and message bodies have been covered.
4.6 Questions
Q4.1 Explain what happens when the expiration interval in an Expires header fi eld in an INVITE expires.
Q4.2 For the three REGISTER requests sent (in this sequence) below, generate appropriate responses to each from the registrar.
REGISTER sip:registrar.athens.gr SIP/2.0
INVITE cross on the wire between a proxy and a UA.
Q4.5 If a SUBSCRIBE is forked by a proxy, and multiple subscriptions are established, how will the watcher know this and keep the subscriptions separate?
Q4.6 Generate a suitable PRACK message in response to the
Q4.7 Explain how PUBLISH can be used to create, refresh, update, and delete event state.
Q4.8 Generate the SUBSCRIBE that could have caused this NOTIFY to
be sent:
Q4.9 How is a subscribe-created dialog terminated?
Q4.10 Explain when a 412 response might be received in response to a PUBLISH. What should the presence UA do after receiving this response?
References
Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. [1]
ley, and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002.
Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) [2]
in the Session Initiation Protocol (SIP),” draft-ietf-sip-gruu-15 (work in progress), October 2007.
SIP Request Messages 109
Rosenberg, J., H. Schulzrinne, and P. Kyzivat, “Indicating User Agent Capabilities in [3]
Session Initiation Protocol (SIP),” RFC 3840, August 2004.
Johnston, A., and O. Levin, “Session Initiation Protocol (SIP) Call Control—Conferencing [4]
for User Agents,” BCP 119, RFC 4579, August 2006.
Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June [5]
2003.
Petrack, S., and L. Conroy, “The PINT Service Protocol: Extensions to SIP and SDP for IP [6]
Access to Telephone Call Services,” RFC 2848, June 2000.
Rosenberg, J., H. Schulzrinne, and O. Levin, “A Session Initiation Protocol (SIP) Event [7]
Package for Conference State,” RFC 4575, August 2006.
Camarillo, G., “The Session Initiation Protocol (SIP) Pending Additions Event Package,”
[8]
RFC 5362, October 2008.
Rosenberg, J., H. Schulzrinne, and R. Mahy, “An INVITE-Initiated Dialog Event [9]
for the Session Initiation Protocol (SIP),” RFC 4235, November 2005.
Burger, E., and M. Dolly, “A Session Initiation Protocol (SIP) Event Package for Key Press [10]
Stimulus (KPML),” RFC 4730, November 2006.
Mahy, R., “A Message Summary and Message Waiting Indication Event Package for the [11]
Session Initiation Protocol (SIP),” RFC 3842, August 2004.
Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” RFC [12]
3856, August 2004.
Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” RFC [13]
3680, March 2004.
Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, April [14]
2003.
Rosenberg, J., “A Watcher Information Event Template-Package for the Session [15]
InitiationProtocol (SIP),” RFC 3857, August 2004.
Clark, A., et al., “RTCP-XR Summary,” draft-ietf-sipping-rtcp-summary-06 (work in [16]
progress), March 2009.
Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” RFC [17]
3903, October 2004.
Fielding, R., et al., “Hypertext Transfer Protocol—HTTP/1.1,” RFC 2616, June 1999.
[18]
Sparks, R., “Internet Media Type message/sipfrag,” RFC 3420, November 2002
[19] .
Levin, O., “Suppression of Session Initiation Protocol (SIP) REFER Method Implicit [20]
Subscription,” RFC 4488, May 2006.
Sparks, R., and A. Johnston, “Session Initiation Protocol Call Control—Transfer,” RFC [21]
5589, June 2009.
Levin, O., and A. Johnston, “Conveying Feature Tags with the Session Initiation Protocol [22]
(SIP) REFER Method,” RFC 4508, May 2006.
Campbell, B., et al., “Session Initiation Protocol (SIP) Extension for Instant Messaging,”
[23]
RFC 3428, December 2002.
Klyne, G., and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message [24]
Format,” RFC 3862, August 2004.
Peterson, J., “Address Resolution for Instant Messaging and Presence,” RFC 3861, August [25]
2004.
Donovan, S., “The SIP INFO Method,” RFC 2976, October 2000.
[26]
Burger, E., H. Kaplan, and C. Holmberg, “Session Initiation Protocol (SIP) INFO Method [27]
and Package Framework,” draft-ietf-sip-info-events-03 (work in progress) January 2009.
Rosenberg, J., and H. Schulzrinne, “Reliability of Provisional Responses in Session Initiation [28]
Protocol (SIP),” RFC 3262, June 2002.
Hoffman, P., L. Masinter, and J. Zawinski, “The mailto URL Scheme,” RFC 2368, July [29]
1998.
Schulzrinne, H., “The tel URI for Telephone Numbers,” RFC 3966, December 2004.
[30]
Camarillo, G., “Message Body Handling in the Session Initiation Protocol (SIP),” [31]
ietf-sip-body-handling-06 (work in progress), March 2009.
111