- •Contents
- •Foreword to the First Edition
- •Preface to the Third Edition
- •Preface to the Second Edition
- •Preface to the First Edition
- •1 SIP and the Internet
- •1.1 Signaling Protocols
- •1.2.2 Data/Link Layer
- •1.2.3 Network Layer
- •1.2.4 Transport Layer
- •1.2 Internet Multimedia Protocol Stack
- •1.2.1 Physical Layer
- •1.2.5 Application Layer
- •1.2.6 Utility Applications
- •1.2.7 Multicast
- •1.3 Internet Names
- •1.4 URLs, URIs, and URNs
- •1.5 Domain Name Service
- •1.5.1 DNS Resource Records
- •1.5.2 Address Resource Records (A or AAAA)
- •1.5.3 Service Resource Records (SRV)
- •1.5.4 Naming Authority Pointer Resource Records (NAPTR)
- •1.5.5 DNS Resolvers
- •1.6 Global Open Standards
- •1.7 Internet Standards Process
- •1.8 A Brief History of SIP
- •1.9 Conclusion
- •References
- •2 Introduction to SIP
- •2.1 A Simple Session Establishment Example
- •2.2 SIP Call with a Proxy Server
- •2.3 SIP Registration Example
- •2.4 SIP Presence and Instant Message Example
- •2.5 Message Transport
- •2.5.1 UDP Transport
- •2.5.2 TCP Transport
- •2.5.3 TLS Transport
- •2.5.4 SCTP Transport
- •2.6 Transport Protocol Selection
- •2.7 Conclusion
- •2.8 Questions
- •References
- •3 SIP Clients and Servers
- •3.1 SIP User Agents
- •3.2 Presence Agents
- •3.3 Back-to-Back User Agents
- •3.4 SIP Gateways
- •3.5 SIP Servers
- •3.5.1 Proxy Servers
- •3.5.2 Redirect Servers
- •3.5.3 Registrar Servers
- •3.6 Uniform Resource Indicators
- •3.7 Acknowledgment of Messages
- •3.8 Reliability
- •3.9 Multicast Support
- •3.10 Conclusion
- •3.11 Questions
- •References
- •4 SIP Request Messages
- •4.1 Methods
- •4.1.1 INVITE
- •4.1.2 REGISTER
- •4.1.5 CANCEL
- •4.1.6 OPTIONS
- •4.1.7 SUBSCRIBE
- •4.1.8 NOTIFY
- •4.1.9 PUBLISH
- •4.1.10 REFER
- •4.1.11 MESSAGE
- •4.1.12 INFO
- •4.1.13 PRACK
- •4.1.14 UPDATE
- •4.2 URI and URL Schemes Used by SIP
- •4.2.1 SIP and SIPS URIs
- •4.2.2 Telephone URLs
- •4.2.3 Presence and Instant Messaging URLs
- •4.3 Tags
- •4.4 Message Bodies
- •4.5 Conclusion
- •4.6 Questions
- •References
- •5 SIP Response Messages
- •5.1 Informational
- •5.1.1 100 Trying
- •5.1.2 180 Ringing
- •5.1.3 181 Call is Being Forwarded
- •5.1.4 182 Call Queued
- •5.1.5 183 Session Progress
- •5.2 Success
- •5.2.2 202 Accepted
- •5.3 Redirection
- •5.3.1 300 Multiple Choices
- •5.3.2 301 Moved Permanently
- •5.3.3 302 Moved Temporarily
- •5.3.4 305 Use Proxy
- •5.3.5 380 Alternative Service
- •5.4.3 402 Payment Required
- •5.4.4 403 Forbidden
- •5.4.5 404 Not Found
- •5.4.6 405 Method Not Allowed
- •5.4.7 406 Not Acceptable
- •5.4.8 407 Proxy Authentication Required
- •5.4.9 408 Request Timeout
- •5.4.11 410 Gone
- •5.4.12 411 Length Required
- •5.4.13 412 Conditional Request Failed
- •5.4 Client Error
- •5.4.1 400 Bad Request
- •5.4.2 401 Unauthorized
- •5.4.14 413 Request Entity Too Large
- •5.4.15 414 Request-URI Too Long
- •5.4.16 415 Unsupported Media Type
- •5.4.17 416 Unsupported URI Scheme
- •5.4.18 417 Unknown Resource Priority
- •5.4.19 420 Bad Extension
- •5.4.20 421 Extension Required
- •5.4.21 422 Session Timer Interval Too Small
- •5.4.22 423 Interval Too Brief
- •5.4.23 428 Use Identity Header
- •5.4.24 429 Provide Referror Identity
- •5.4.25 430 Flow Failed
- •5.4.26 433 Anonymity Disallowed
- •5.4.27 436 Bad Identity-Info Header
- •5.4.29 438 Invalid Identity Header
- •5.4.30 439 First Hop Lacks Outbound Support
- •5.4.31 440 Max-Breadth Exceeded
- •5.4.32 470 Consent Needed
- •5.4.33 480 Temporarily Unavailable
- •5.4.34 481 Dialog/Transaction Does Not Exist
- •5.4.35 482 Loop Detected
- •5.4.36 483 Too Many Hops
- •5.4.37 484 Address Incomplete
- •5.4.38 485 Ambiguous
- •5.4.39 486 Busy Here
- •5.4.40 487 Request Terminated
- •5.4.41 488 Not Acceptable Here
- •5.4.42 489 Bad Event
- •5.4.43 491 Request Pending
- •5.4.44 493 Request Undecipherable
- •5.4.45 494 Security Agreement Required
- •5.5 Server Error
- •5.5.1 500 Server Internal Error
- •5.5.2 501 Not Implemented
- •5.5.3 502 Bad Gateway
- •5.5.4 503 Service Unavailable
- •5.5.5 504 Gateway Timeout
- •5.5.6 505 Version Not Supported
- •5.5.7 513 Message Too Large
- •5.5.8 580 Preconditions Failure
- •5.6 Global Error
- •5.6.1 600 Busy Everywhere
- •5.6.2 603 Decline
- •5.6.3 604 Does Not Exist Anywhere
- •5.6.4 606 Not Acceptable
- •5.7 Questions
- •References
- •6 SIP Header Fields
- •6.1 Request and Response Header Fields
- •6.1.1 Accept
- •6.1.2 Accept-Encoding
- •6.1.3 Accept-Language
- •6.1.4 Alert-Info
- •6.1.5 Allow
- •6.1.6 Allow-Events
- •6.1.7 Answer-Mode
- •6.1.8 Call-ID
- •6.1.9 Contact
- •6.1.10 CSeq
- •6.1.11 Date
- •6.1.12 Encryption
- •6.1.13 Expires
- •6.1.14 From
- •6.1.15 History Info
- •6.1.16 Organization
- •6.1.17 Path
- •6.1.19 Record-Route
- •6.1.20 Recv-Info
- •6.1.21 Refer-Sub
- •6.1.22 Retry-After
- •6.1.23 Subject
- •6.1.24 Supported
- •6.1.25 Timestamp
- •6.1.27 User-Agent
- •6.2 Request Header Fields
- •6.2.1 Accept-Contact
- •6.2.2 Authorization
- •6.2.3 Call-Info
- •6.2.4 Event
- •6.2.5 Hide
- •6.2.6 Identity
- •6.2.7 Identity-Info
- •6.2.8 In-Reply-To
- •6.2.9 Info-Package
- •6.2.10 Join
- •6.2.11 Priority
- •6.2.12 Privacy
- •6.2.13 Proxy-Authorization
- •6.2.14 Proxy-Require
- •6.2.15 P-OSP-Auth-Token
- •6.2.16 P-Asserted-Identity
- •6.2.17 P-Preferred-Identity
- •6.2.18 Max-Breadth
- •6.2.19 Max-Forwards
- •6.2.20 Reason
- •6.2.21 Refer-To
- •6.2.22 Referred-By
- •6.2.23 Reply-To
- •6.2.24 Replaces
- •6.2.25 Reject-Contact
- •6.2.26 Request-Disposition
- •6.2.27 Require
- •6.2.28 Resource-Priority
- •6.2.29 Response-Key
- •6.2.30 Route
- •6.2.31 RAck
- •6.2.32 Security-Client
- •6.2.33 Security-Verify
- •6.2.34 Session-Expires
- •6.2.35 SIP-If-Match
- •6.2.36 Subscription-State
- •6.2.37 Suppress-If-Match
- •6.2.38 Target-Dialog
- •6.2.39 Trigger-Consent
- •6.3 Response Header Fields
- •6.3.1 Accept-Resource-Priority
- •6.3.2 Authentication-Info
- •6.3.3 Error-Info
- •6.3.4 Flow-Timer
- •6.3.5 Min-Expires
- •6.3.7 Permission-Missing
- •6.3.8 Proxy-Authenticate
- •6.3.9 Security-Server
- •6.3.10 Server
- •6.3.11 Service-Route
- •6.3.12 SIP-ETag
- •6.3.13 Unsupported
- •6.3.14 Warning
- •6.3.15 WWW-Authenticate
- •6.3.16 RSeq
- •6.4 Message Body Header Fields
- •6.4.1 Content-Encoding
- •6.4.2 Content-Disposition
- •6.4.3 Content-Language
- •6.4.4 Content-Length
- •6.4.5 Content-Type
- •6.4.6 MIME-Version
- •6.5 Questions
- •References
- •7 Wireless, Mobility, and IMS
- •7.1 IP Mobility
- •7.2 SIP Mobility
- •7.4 IMS Header Fields
- •7.5 Conclusion
- •7.6 Questions
- •References
- •8 Presence and Instant Messaging
- •8.1 Introduction
- •8.2 History of IM and Presence
- •8.3 SIMPLE
- •8.4 Presence with SIMPLE
- •8.4.1 SIP Events Framework
- •8.4.2 Presence Bodies
- •8.4.3 Resource Lists
- •8.4.4 Filtering
- •8.4.6 Partial Publication
- •8.4.7 Presence Documents Summary
- •8.5 Instant Messaging with SIMPLE
- •8.5.1 Page Mode Instant Messaging
- •8.5.4 Message Composition Indication
- •8.5.5 Multiple Recipient Messages
- •8.5.6 Session Mode Instant Messaging
- •8.6 Jabber
- •8.6.1 Standardization as Extensible Messaging and Presence Protocol
- •8.6.2 Interworking with SIMPLE
- •8.6.3 Jingle
- •8.6.4 Future Standardization of XMPP
- •8.7 Conclusion
- •8.8 Questions
- •References
- •9 Services in SIP
- •9.1 Gateway Services
- •9.2 SIP Trunking
- •9.3 SIP Service Examples
- •9.4 Voicemail
- •9.5 SIP Video
- •9.6 Facsimile
- •9.7 Conferencing
- •9.7.1 Focus
- •9.7.2 Mixer
- •9.8 Application Sequencing
- •9.9 Other SIP Service Architectures
- •9.9.1 Service Oriented Architecture
- •9.9.2 Servlets
- •9.9.3 Service Delivery Platform
- •9.10 Conclusion
- •9.11 Questions
- •References
- •10 Network Address Translation
- •10.1 Introduction to NAT
- •10.2 Advantages of NAT
- •10.3 Disadvantages of NAT
- •10.4 How NAT Works
- •10.5 Types of NAT
- •10.5.1 Endpoint Independent Mapping NAT
- •10.5.2 Address Dependent Mapping NAT
- •10.5.3 Address and Port Dependent Mapping NAT
- •10.5.4 Hairpinning Support
- •10.5.5 IP Address Pooling Options
- •10.5.6 Port Assignment Options
- •10.5.7 Mapping Refresh
- •10.5.8 Filtering Modes
- •10.6 NAT Mapping Examples
- •10.7 NATs and SIP
- •10.8 Properties of a Friendly NAT or How a NAT Should BEHAVE
- •10.9 STUN Protocol
- •10.10 UNSAF Requirements
- •10.11 SIP Problems with NAT
- •10.11.1 Symmetric SIP
- •10.11.2 Connection Reuse
- •10.11.3 SIP Outbound
- •10.12 Media NAT Traversal Solutions
- •10.12.1 Symmetric RTP
- •10.12.2 RTCP Attribute
- •10.12.3 Self-Fixing Approach
- •10.13 Hole Punching
- •10.14 TURN: Traversal Using Relays Around NAT
- •10.15 ICE: Interactive Connectivity Establishment
- •10.16 Conclusion
- •10.17 Questions
- •References
- •11 Related Protocols
- •11.1 PSTN Protocols
- •11.1.1 Circuit Associated Signaling
- •11.1.2 ISDN Signaling
- •11.1.3 ISUP Signaling
- •11.2 SIP for Telephones
- •11.3 Media Gateway Control Protocols
- •11.4.1 Introduction to H.323
- •11.4.2 Example of H.323
- •11.4.3 Versions
- •References
- •12 Media Transport
- •12.1 Real-Time Transport Protocol (RTP)
- •12.2 RTP Control Protocol (RTCP)
- •12.2.1 RTCP Reports
- •12.2.2 RTCP Extended Reports
- •12.3 Compression
- •12.4.1 Audio Codecs
- •12.4.2 Video Codecs
- •12.5 Conferencing
- •12.6 ToIP—Conversational Text
- •12.7 DTMF Transport
- •12.8 Questions
- •References
- •13 Negotiating Media Sessions
- •13.1 Session Description Protocol (SDP)
- •13.1.1 Protocol Version
- •13.1.2 Origin
- •13.1.3 Session Name and Information
- •13.1.5 E-Mail Address and Phone Number
- •13.1.6 Connection Data
- •13.1.7 Bandwidth
- •13.1.8 Time, Repeat Times, and Time Zones
- •13.1.9 Encryption Keys
- •13.1.10 Media Announcements
- •13.1.11 Attributes
- •13.2 SDP Extensions
- •13.3 The Offer Answer Model
- •13.3.1 Rules for Generating an Offer
- •13.3.2 Rules for Generating an Answer
- •13.3.3 Rules for Modifying a Session
- •13.3.4 Special Case—Call Hold
- •13.4 Static and Dynamic Payloads
- •13.5 SIP Offer Answer Exchanges
- •13.6 Conclusion
- •13.7 Questions
- •References
- •14 SIP Security
- •14.1 Basic Security Concepts
- •14.1.1 Encryption
- •14.1.2 Public Key Cryptography
- •14.1.4 Message Authentication
- •14.2 Threats
- •14.3 Security Protocols
- •14.3.1 IPSec
- •14.3.3 DNSSec
- •14.3.4 Secure MIME
- •14.4 SIP Security Model
- •14.4.1 SIP Digest Authentication
- •14.4.2 SIP Authentication Using TLS
- •14.4.3 Secure SIP
- •14.4.4 Identity
- •14.4.5 Enhanced SIP Identity
- •14.6 Media Security
- •14.6.1 Non-RTP Media
- •14.6.2 Secure RTP
- •14.6.3 Keying SRTP
- •14.6.4 Best Effort Encryption
- •14.6.5 ZRTP
- •14.7 Questions
- •References
- •15 Peer-to-Peer SIP
- •15.1 P2P Properties
- •15.2 P2P Properties of SIP
- •15.3 P2P Overlays
- •15.4 RELOAD
- •15.5 Host Identity Protocol
- •15.6 Conclusion
- •15.7 Questions
- •References
- •16 Call Flow Examples
- •16.1 SIP Call with Authentication, Proxies, and Record-Route
- •16.2 SIP Call with Stateless and Stateful Proxies with Called Party Busy
- •16.3 SIP to PSTN Call Through Gateways
- •16.4 PSTN to SIP Call Through a Gateway
- •16.5 Parallel Search
- •16.6 Call Setup with Two Proxies
- •16.7 SIP Presence and Instant Message Example
- •References
- •17 Future Directions
- •17.2 More Extensions
- •17.3 Better Identity
- •17.4 Interdomain SIP
- •17.5 Making Features Work Better
- •17.6 Emergency Calling
- •17.7 More SIP Trunking
- •17.9 Improved NAT Traversal
- •17.10 Security Deployment
- •17.11 Better Interoperability
- •References
- •A.1 ABNF Rules
- •A.2 Introduction to XML
- •References
- •About the Author
104 |
SIP: Understanding the Session Initiation Protocol |
4.2.3Presence and Instant Messaging URLs
The pres URL scheme is defined [25] as a URL scheme that represents a “presentity” or presence agent. The im URL scheme is defined [25] as a URL scheme that represents an “instant inbox” or an instant message client. Both URL schemes do not represent a new protocol but are resolved using DNS SRV resource records, which return another URI that indicates the actual presence or instant messaging protocol. For example, if the presence agent reference by the presence URL:
pres:user@example.com
supports SIP presence, the DNS SRV query would return a SIP URI, for example:
sip:user@example.com
This would then allow a presence agent to send a SUBSCRIBE to this SIP URI to obtain the presence agent of this user.
The same procedure would be used for resolving an im URL into a SIP URI for sending a MESSAGE request.
4.3 Tags
A tag is a cryptographically random number with at least 32 bits of randomness, which is added to To and From headers to uniquely identify a dialog. The examples in Chapters 2 and 16 show the use of the tag header parameter. The To header in the initial INVITE will not contain a tag. A caller must include a tag in the From header, although an RFC 2543 UA generally will not do so as it is optional in that specification. Excluding 100 Trying, all responses will have a tag added to the To header. The sending or receiving of a response containing a From tag creates an early dialog. A tag returned in a 200 OK response is then incorporated as a dialog identifier and used in all future requests for this Call-ID. A tag is never copied across calls. Any response generated by a proxy will have a tag added by the proxy. An ACK generated by either a UA or a proxy will always copy the From tag of the response in the ACK request.
If a UAC receives responses containing different tags, this means that the responses are from different UASs, and the INVITE has been forked. It is up to the UAC as to how to deal with this situation. For example, the UAC could establish separate sessions with each of the responding UAS. The dialogs would contain the same From, Call-ID, and CSeq, but would have different tags in the To header. The UAC also could BYE certain legs and establish only one session.
Note that tags are not part of the To or From URI but are part of the header and always placed outside any “<>”.
SIP Request Messages |
105 |
4.4 Message Bodies
Message bodies in SIP may contain various types of information. They may contain 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 defined function is render, which means that the message body should be presented to the user or otherwise used or displayed. This could be used to pass a small JPEG image file 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 encoding scheme of the message body is indicated in the Content-Encoding header. If not specified, the encoding is assumed to be text/plain. The specification 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 message 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 bodies 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 defined, 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:refertarget@carol.example.com SIP/2.0
Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac To: sip:refertarget@carol.example.com
106 |
SIP: Understanding the Session Initiation Protocol |
From: <sip:referree@referree.example>;tag=2909034023 Call-ID: 9023940-a34658d
CSeq: 9823409 INVITE Max-Forwards: 70
Contact: <sip:referree@bob.example.com> Referred-By: sip:referror@alice.example.com
;cid=%3C20398823.2UWQFN309shb3@alice.example.com%3E Content-Type: multipart/mixed; boundary=-*-boundary-*- Content-Length: ...
—-*-boundary-*-
Content-Type: application/sdp
Content-Length: ...
v=0
o=referree 2890844526 2890844526 IN IP4 referree.example s=Session SDP
c=IN IP4 referree.example t=0 0
m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
—-*-boundary-*-
Content-Type: multipart/signed; protocol=”application/pkcs7-signature”; micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@alice.example.com> Content-Length: ...
-another-boundary- Content-Type: message/sipfrag
Content-Disposition: auth-id; handling=optional
From: sip:referror@alice.example.com Date: Thu, 21 Feb 2002 13:02:03 GMT Call-ID: 2203900ef0299349d9209f023a
Refer-To: sip:refertarget@carol.example.com Referred-By: sip:referror@alice.example.com
;cid=%3C20398823.2UWQFN309shb3@alice.example.com%3E
-another-boundary-
Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s ;handling=required
(S/MIME data goes here)
—-*-boundary-*—-
Between each body part is a string, in this example -*-boundary-*- which is defined in the Content-Type header field.
SIP Request Messages |
107 |
4.5 Conclusion
This chapter covered the six base methods in RFC 3261 plus the eight extension methods defined in other RFCs. In addition, SIP URIs, URLs, tags, and message bodies have been covered.
4.6Questions
Q4.1 Explain what happens when the expiration interval in an Expires header field 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
Via: SIP/2.0/UDP 201.202.203.204:5060;branch=z9hG4bK231U3
Max-Forwards:70
To: sip:euclid@athens.gr
From: <sip:euclid@athens.gr>;tag=543131
Call-ID: 48erl8132409wqer
CSeq: 1 REGISTER
Contact: <sip:euclid@parthenon.athens.gr>
Content-Length: 0
REGISTER sip:registrar.athens.gr SIP/2.0
Via: SIP/2.0/UDP 201.202.203.204:5060;branch=z9hG4bK3r13
Max-Forwards:70
To: sip:euclid@athens.gr
From: < sip:euclid@athens.gr>;tag=75653
Call-ID: 48erl8132409wqer
CSeq: 2 REGISTER
Contact: <mailto:euclid@geometry.org>
Content-Length: 0
REGISTER sip:registrar.athens.gr SIP/2.0
Via: SIP/2.0/UDP 201.202.203.204:5060;branch=z9hG4bK3313
Max-Forwards:70
To: sip:euclid@athens.gr
From: <sip:euclid@athens.gr>;tag=4d31f31
Call-ID: 48erl8132409wqer
CSeq: 3 REGISTER
Content-Length: 0
Q4.3 Is a message body permitted in an ACK? Give an example of this usage.
Q4.4 Explain what happens if a 200 OK and the CANCEL for the 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?