SIP Working Group H. Kaplan Internet Draft Spacely Spackets Intended status: Standards Track R. Penfield Updates: 3261, 3262, 3263, and many, many more Spacely Spackets Expires: October 1, 2008 Alice Collier Atlanta.com Bob Khaled Biloxi.com April 1, 2008 Session Initiation Protocol (SIP) Version 4.0: P2P2PSIP draft-kaplan-sip-four-oh-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kaplan Expires October 1, 2008 [Page 1] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Abstract This document defines a new and improved version of SIP, which tastes great and is less filling than the previous SIP. This draft updates all previous and future RFCs related to SIP in SIPPING, SIMPLE, MMUSIC, BEHAVE, and so on. Table of Contents 1. Introduction................................................5 1.1. Overview of P2P2PSIP Functionality......................6 2. Terminology.................................................7 3. Applicability...............................................7 4. Overview of the Operation...................................7 5. Structure of the Protocol..................................11 6. Definitions................................................11 7. SIP Messages...............................................13 7.1. Requests...............................................13 7.2. Responses..............................................13 7.3. Header Fields, Bodies, and all that....................14 8. General User Agent Behavior................................14 8.1. UAC Behavior...........................................14 8.1.1 Generating the Request...............................14 8.1.1.1 Request-URI........................................14 8.1.1.2 To.................................................15 8.1.1.3 From...............................................15 8.1.1.4 Call-ID............................................15 8.1.1.5 Cseq...............................................15 8.1.1.6 Max-Forwards.......................................15 8.1.1.7 Event..............................................15 8.1.1.8 Session-State......................................16 8.1.1.9 Expires............................................16 8.1.1.10 Contact...........................................16 8.1.2 Processing Responses.................................16 8.1.2.1 Processing 300 Responses...........................16 8.1.2.2 Processing 400 Responses...........................16 8.1.2.3 Processing 500 Responses...........................17 8.1.2.4 Processing 600 Responses...........................17 8.1.2.5 Processing 700 Responses...........................17 9. SIP and SIPSS URIs.........................................17 10. Header Fields..............................................18 10.1. New Headers............................................18 10.1.1 Asserted-ID.........................................18 10.1.2 Diversion...........................................18 10.1.3 Session-State.......................................19 10.1.4 Spit-Score..........................................19 10.2. Other Headers..........................................19 10.2.1 Call-ID.............................................19 Kaplan Expires October 1, 2008 [Page 2] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 10.2.2 Contact.............................................19 10.2.3 Identity and Identity-Info..........................20 10.3. Deprecated Headers.....................................20 11. Forking, Knifing and Spooning..............................21 12. Resolution of E.164 NUMbers (RENUM)........................23 13. Session Description Protocol v2.0 (SDP2)...................24 13.1. SDP2 Offer-Answer Model................................25 14. Network Address Translator (NAT) Traversal.................26 14.1. Fast Interoperable Relay Establishment (FIRE)..........27 14.2. Dummy Relay Internet Nat Keepalive (DRINK).............28 14.3. Traversal With Internet Server Transport (TWIST).......28 14.3.1 Lightweight Endpoint Media Over Network TWIST (LEMON TWIST)..............................................28 14.4. Benevolent Random Internet Message Sending to Test Other Network Elements (BRIMSTONE)...........................29 15. SIPv4 Transport (hint: it's UDP)...........................29 15.1. SIP Has Only Udp Transport (SHOUT).....................30 16. SIP Compression Underlayer (SCU)...........................31 17. Secure/MIME/(Royalty-free)/Generation-two (S/MIME/$0/G)....33 18. Secure Real-time Transport Protocol v2 (SRTP2).............34 19. Message Session Relay Protocol v2 (MSRP2)..................35 20. Poison Pills...............................................36 21. Security Considerations....................................36 22. Benefits of SIPv4..........................................37 23. Acknowledgements...........................................38 24. IANA Considerations........................................38 25. References.................................................38 25.1. Normative References...................................38 25.2. Informative References.................................39 Authors' Addresses...............................................41 Intellectual Property Statement..................................42 Full Copyright Statement.........................................42 Acknowledgment...................................................42 Kaplan Expires October 1, 2008 [Page 3] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 DON'T PANIC Kaplan Expires October 1, 2008 [Page 4] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 1. Introduction SIP version 2.0, originally defined in RFC 2543 and updated by RFC 3261 [RFC3261], has become quite popular among the "in" crowd. It has, however, not been used in a way that people think it should be used, and has several problems caused by the growth in complexity of the protocol, ambiguity in usage, lack of security, and need for backwards compatibility. This draft makes no serious attempt to fix any of that. Instead, this draft is aimed at creating a new version of SIP, so that manufacturers can sell new equipment and software, to help the global economy. This in turn will increase tax revenue for governments, which eventually may lead to increased funds for feeding children. Therefore the ultimate goal of this draft is to feed starving children. Thus, to accomplish the goal of feeding starving children by selling new equipment or software, a new SIP version is required which is not backwards compatible: SIP v4.0. One may wonder why it isn't numbered SIP v3.0 - the answer lies in market research. After the equivalent of hundreds of man-years of careful research (accomplished in 2 minutes of Google searching), we have determined that even-numbered versions of protocols have far greater chance of success than odd-numbered versions. For example, IPv4, BGP4, SNMPv2, H.323v2, and SIPv2 are all largely successful, while IPv5, BGP3, SNMPv3, and H.323v3 were not (SIPv3 did not even make it into a draft!). [Note: IPv6 does not count as purely even-numbered because it is actually 2 times 3, an odd number, whereas IPv4 is both even and the square of even numbers, which explains IPv6's relative failure thus far] In order to convince customers of the need for adopting this new version, however, P2P2PSIP addresses the following issues in SIPv2: 1. Lack of end-to-end deployment 2. No integrated NAT traversal 3. No end-to-end security 4. Too many transports 5. Too many RFCs and drafts 6. Too many "Standards Bodies" 7. Early media issues 8. HERFP caused by forking 9. Only Alice and Bob can make phone calls 10. Lack of "P2P" in the title One may wonder why the currently active P2PSIP WG and architecture is not being used, instead of defining a new SIP protocol version. We investigated P2PSIP, and found that they plan to use overlays to form closed communities, effectively implementing a "Walled Kaplan Expires October 1, 2008 [Page 5] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Garden". Apparently it's ok to form Walled Gardens as long as the members of the Garden all own iPhones or run some variant of Linux. Instead, we prefer an open protocol available to all, similar to SIPv2. The rest of this draft is defined assuming the reader has a basic knowledge of SIP and its extensions and related works: MSRP, ICE, SDP, RTP, UDP, and other TLA's and ETLA's - if the reader does not know what a "TLA" is: RTFM. This draft is generally written only describing the differences from their RFCs, especially RFC 3261 [RFC3261], to reduce the size of the document in the hopes that implementers read it. One other minor note: the examples are normative, while the text is informative. This follows more closely the way people under tight development timeframes (and who isn't?) actually implement things, and should therefore improve interoperability. 1.1. Overview of P2P2PSIP Functionality Like RFC 3261 and its extensions (collectively called "SIPv2" in this document), P2P2PSIP ("SIPv4") is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIPv4 can also invite participants to already existing sessions, such as conferences. Media can be added to (and removed from) an existing session. Blah, blah, etc., etc. Unlike RFC 3261, there is only one method: INVITE. There is no ACK, BYE, REGISTER, CANCEL, PRACK, UPDATE, INFO, MESSAGE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, etc. The concept here is simple: to make a session request (a "call") you use INVITE to "invite" a party to a session. To end a call you INVITE the UA to leave. To register, you INVITE a Registrar to send INVITEs to you. To send a Instant Message you INVITE a UA to render the MIME attachment. To subscribe to event state notifications you INVITE a UAS to send you INVITEs for events, and the notification is an INVITE to the UAC of an event occurring. To transfer a call you INVITE the caller to call someone else, or to join another session. You get the idea. These "intentions" of the INVITE are handled with invite-packages, defined later if we have time. Also, SIPv4 only has final responses. There are no provisional responses, including no 100 Trying. This follows the sage advice: "Do, or do not. There is no try." If the request was delivered (received and processed), or failed to be delivered, a final response is generated. Kaplan Expires October 1, 2008 [Page 6] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Furthermore, there are no "Proxies" in P2P2PSIP. There are only UAC's and UAS's and combinations thereof: B2BUA's. An INVITE request can get "passed on" by UA's, which makes them B2BUA's. Clearly without Proxies, and all requests going between UA's, the protocol is intrinsically end-to-end. It may just be end-to-end- to-end, and thus "P2P2P". This solves all sorts of problems related to end-to-end security, integrity, and identity. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. All other words SHOULD be interpreted as described by the Oxford English Dictionary [oed], which MAY be considered almost as authoritative for word definitions as the IETF. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft applies to [RFC3261], [RFC3262], [RFC3263], and a whole load of other RFCs. 4. Overview of the Operation This section introduces the basic operations of SIPv4 using simple examples. This section is normative in nature and is about the only thing that will probably work. The first example shows the basic functions of P2P2PSIP: 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, through three B2BUA's, Peter, Paul and Mary. (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 limp-phone) to call Bob on his SIP phone over the Internet. This typical arrangement was called the "SIP Trapezoid" in SIPv2, but in SIPv4 is often referred to as the "SIP Convex Pentagon" as shown by the geometric shape of the dotted lines in Figure 1. The author Dan Brown also notes in his upcoming "The Rosenberg Code" book that secretly it can also be drawn as the "SIP Pentagram" as shown in figure 2, which shows the Freemasons influenced the design of SIP to call each other. [Spoiler alert: in the "The Rosenberg Code", the Kaplan Expires October 1, 2008 [Page 7] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 riddles in the works of Rosenberg show the Holy Grail is a guy named Nathaniel Crossing, and in a STUNning TURN of events, border agents stop Robert Langdon from puncturing Nat Crossing with an ICE pick] In SIPv4, other geometric shapes are possible, up to the "SIP tetracontakaitetragon" which has fourty-four sides; therefore Max- Forwards cannot be greater than 42 (which coincidentally is also the length of this draft, and the answer to life, the universe, and everything). [Note: supporting geometric shapes of tetracontakaipentagon and larger are for future study] Alice "calls" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined later, and here (so you don't have to skip ahead). It has a similar form to an email address, typically containing a username and a host name, and the username is even more typically a phone number and the domain name meaningless. In fact, in SIPv4 ONLY telephone numbers are allowed in signaled usernames (in the From, To, etc.) on the wire. In this example case, it is sip:17815551212@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:12128675309@atlanta.com. Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book, such that the username is not a number but any random alphanumeric sequence such as are found in email addresses. In the real world that's highly unlikely, and in fact Alice would have pressed buttons for a phone number, and simply set the domain portion to her service provider. But this is not the real world, this is the IETF. So we will pretend it can be an email address; but if Alice enters one then her UA MUST convert it to an E.164 phone number. The mechanism for doing this is explained later, using a DNS lookup mechanism called RENUM (for "Reverse ENUM"). SIPv4 also provides a secure URI, called a SIPSS URI. An example would be sipss:17815551212@biloxi.com. Unlike "SIPS" of RFC 3261, a call made to a SIPSS URI truly guarantees that secure, encrypted transport (namely DTLS) or IP layer (IPSEC, VPN, whatever) is used to carry all SIP messages from the caller, through any number of B2BUA's and domains, 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, or any B2BUA. The guarantee is assured, because the extra "S" is used. Previously, a single "S" was appended to "SIP", but that last "S" is usually for "Savings", and has been shown previously, an even-number is better anyway, so two "S" at the end is more likely to succeed. Kaplan Expires October 1, 2008 [Page 8] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 birmingham.com . B2BUA . . . atlanta.com biloxi.com . B2BUA B2BUA . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's limpphone media SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | |--------------->| INVITE F3 | | | |--------------->| | | | 200 OK F4 | | | 200 OK F5 |<---------------| | 200 OK F6 |<---------------| | |<---------------| | | | | | INVITE F7 | | | INVITE F8 |<---------------| | INVITE F9 |<---------------| | |<---------------| | | | 200 OK F10 | | | |--------------->| 200 OK F11 | | | |--------------->| 200 OK F12 | | | |--------------->| | Media Session | |<================================================>| | INVITE F13 | | | |--------------->| INVITE F14 | | | |--------------->| INVITE F15 | | | |--------------->| | | | 200 OK F16 | | | 200 OK F17 |<---------------| | 200 OK F18 |<---------------| | |<---------------| | | | | Figure 1: P2P2PSIP session setup example with "SIP polygon", also known as "SIP House with Gambrel roof" SIPv4 is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular function on the server and exactly one response. Unlike SIPv2, P2P2PSIP has no 1xx responses - if the INVITE was received by the UAS, a 200 is sent. It does NOT mean the callee has picked up the phone. It does not mean much of anything at a higher layer - it just means the request was received and processed successfully. The actual state of the session is handled by a Session-State header, defined later. Kaplan Expires October 1, 2008 [Page 9] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 birmingham.com B2BUA . . . . . . . Alice's . . . . . . . . . . . . . . . . . . . . . Bob's limpphone . . media . . SIP Phone . . . . . . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. biloxi.com atlanta.com B2BUA B2BUA Figure 2: Secret Freemason "SIP Pentagram" shape, per Dan Brown 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, but fewer than SIPv2. Example message F1: INVITE sip:17815551212@biloxi.com SIP/2x2.0 Max-Forwards: 42 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e-667102223144;callid=VENUS-1234 CSeq: 314159 INVITE Contact: Content-Type: application/sdp2 Content-Length: 142 (Alice's SDP2 not shown) Note that in the above example the media is shown to go directly between Alice and Bob. That is not required in SIPv4. Instead, it may go through any number of the B2BUA's, but to do so makes them also B2BMAs. Kaplan Expires October 1, 2008 [Page 10] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 5. Structure of the Protocol The structure of SIPv4 is similar in nature to SIPv2, but slightly different. It is up to the reader to guess how it is different, or just take our word for it. 6. Definitions SIPv2: SIP as defined by RFC 3261 and many of its extension RFCs and drafts. SIPv4: P2P2PSIP, as defined by this document. SDP2: Session Description Protocol version 2, a replacement for SDP [RFC4566], as defined by this document. B2BUA: A Back-to-Back UAC and UAS, which forwards on and changes INVITEs based on some arbitrary policies. B2BMA: A Back-to-Back Media Agent, which relays media for various good and wholesome purposes. SBC: SIP Behavior Corrector, a device which used to be used primarily for security, but is now also used to fix other people's bugs or interop issues. This will eventually make its acronym become ATT (All-purpose Translation Technology) instead of SBC. SCU: Signaling Compression Underlayer, a.k.a, "SQ", a replacement for SigComp [RFC3320], as defined by this document. HEADQUARTERS: a big building where generals meet, but that's not important right now. RENUM: Resolution of E.164 NUMbers, or Reverse ENUM, a mechanism to learn the E.164 phone number for a given SIP email-style alphanumeric URI. NAT: Network Address (and possibly port) Translator. FIRE: Fast Interoperable Relay Establishment, a replacement for ICE [draft-ice], as defined by this document. HOSPITAL: a big building with patients, but that's not important right now. DRINK: Dummy Relay Internet NAT Keepalive, a replacement for keepalives in sip-outbound [draft-outbound] and RTP no-op [draft-no-op]. Kaplan Expires October 1, 2008 [Page 11] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 TWIST: Traversal With Internet Server Transport, a replacement for TURN [draft-turn]. LEMON TWIST: Lightweight Endpoint Media Over Network TWIST, a usage of TWIST for media. BRIMSTONE: Benevolent Random Internet Message Sending to Test Other Network Elements, a replacement for STUN connectivity- checks. SHOUT: SIP Has Only UDP Transport, a layer between UDP and SIPv4 to avoid IP fragmentation for SIP/UDP usage. COCKPIT: the little room in the front of the plane where the pilots sit, but that's not important now. MSRP2: Message Session Relay Protocol, a replacement for MSRP [RFC4975], as defined by this document. SRTP2: Secure Real-time Transport Protocol version 2, a replacement for SRTP [RFC3711], as defined by this document. S/MIME/$0/G: Secure / Multipurpose Internet Mail Extension (MIME) / (Royalty-free) / Generation-two, a replacement for S/MIME, as defined by this document. The same definitions as noted in RFC 3261 apply, with the exception that all the terms "Proxy" are hereby replaced with "B2BUA", and the following changes as well: Call Stateful: Removed. Everything in P2P2PSIP is call stateful, so there is no need for this definition. Final Response: Removed. All responses are final. Informational Response: Removed - there aren't any. Loose Routing: Removed. There is no Route header, and only one form of routing: strict-ish. Method: Removed. There is only one method type: INVITE, so why name its token field? Provisional Response: Removed - there aren't any. Kaplan Expires October 1, 2008 [Page 12] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Proxy, Proxy-Server: Removed. These are evil middle-boxes and break end-to-end. If someone builds one, it will be called "Device which shall not be named". Route Set: Removed. Stateful Proxy: Removed. Everything is session-stateful, and there are no Proxies. Stateless Proxy: Removed. (see above) 7. SIP Messages SIPv4 has the same message characteristics as SIPv2. Pretty much. 7.1. Requests The format of the start line is the same as SIPv2. Method: Unlike SIPv2, SIPv4 has only one Method: INVITE. Request-URI: Same as SIPv2. SIP-Version: Since this is SIPv4, the version is indicated by "SIP/2x2.0". 7.2. Responses SIPv4 responses are similar in syntax to SIPv2 responses, except every response has a Contact header, the content of which depends on the response. Furthermore, there are only six total response numbers and types: 200, 300, 400, 500, 600, and 700. When defining response codes, SIPv4 defines them in terms of what the UAC should do when receiving them, instead of in terms of when the UAS should send them. In other words, the condition which caused the response does not really matter - what matters is what the UAS wants the UAC to do immediately and in the future based on getting it. The following are the only permissible responses, and as discussed above, their semantic meaning from the UAC's perspective (not the UAS'): 200: Success -- the UAC should be happy and hang tight; the UAS claims the request was successfully received, understood, and processed. Kaplan Expires October 1, 2008 [Page 13] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 300: Redirection -- the UAC should retry the request to the URI contained in the Contact header. 400: Client Error -- the UAC can try sending the request again elsewhere, but not to the same B2BUA/UAS in the Contact. 500: Server Error -- if there's an Expires header, the UAC can try sending it again after that; otherwise send it elsewhere. 600: Global Failure -- don't bother trying this request to anyone, anywhere, ever again. 700: Authorization Required -- the UAC should resend the request to the same place, but with a digest-challenge response based on the authorization info in the 700. 7.3. Header Fields, Bodies, and all that Same as SIPv2 generally, unless we say otherwise later. 8. General User Agent Behavior The same concepts apply for SIPv4 as SIPv2. B2BUA's will be discussed later. 8.1. UAC Behavior This section covers UAC behavior. 8.1.1 Generating the Request A valid SIPv4 request generated by a UAC (or B2BUA for that matter) MUST, at a minimum, include the following header fields: To, From, Cseq, Call-ID, Max-Forwards, Event, Session-State, Expires, and Contact. Note that Via no longer exists. 8.1.1.1 Request-URI The initial Request-URI of the message MUST be set to the value of the URI in the To field for dialog-initiating requests. For in- dialog requests, it MUST be set to the Contact URI received in a previous response or request. Note that this doesn't mean the UAC will send it directly to the request-URI, but it probably should if it wants it to work. Kaplan Expires October 1, 2008 [Page 14] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 8.1.1.2 To The To header field is like it was in SIPv2, except it must be populated with a SIP or SIPSS URI (there is no "SIPS"). Furthermore, as noted previously, only phone number formats are allowed in the user portion of the URI. As in SIPv2, a tag parameter is not used for requests outside of a dialog. Once a receiver responds, they will insert the To-tag, and call out "tag, you're it!". 8.1.1.3 From The From header works as in SIPv2, except it must be populated with a SIP or SIPSS URI only, and the user portion must be a phone number format. 8.1.1.4 Call-ID The Call-Id header is similar to SIPv2, except a "localid@host" format is not allowed and MUST NOT be used. In particular, there must be no IP Address or FQDN in the Call-Id, or else the request will be rejected. Instead, a UUID or MAC Address MAY be used. [Note: MAC addresses are not actually globally unique, but they're ok to use because people think they're globally unique (often IP Addresses aren't globally unique either!)] A "callid" header parameter is also included, so that spooning can be detected (see section 11). 8.1.1.5 Cseq The CSeq header works as it did in SIPv2, except there's no need to populate a Method, since INVITE is the only method. But you can still populate it if it makes you feel better. 8.1.1.6 Max-Forwards The Max-Forwards header works as it did in SIPv2, except the number MUST be 42 or less, since the largest geometric shape for a SIPv4 call flow is a tetracontakaitetragon. The number 42 should be used as the starting number for most cases. 8.1.1.7 Event The Event header is similar in nature and syntax to the same header from [RFC3265] (which this draft obsoletes). It is used to indicate the INVITE event-package used for the INVITE session, such as "register", "call", "im", "info", "transfer", "hold", and so on, possibly defined later. Kaplan Expires October 1, 2008 [Page 15] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 8.1.1.8 Session-State The Session-State header is similar in nature and syntax to the Subscription-State header in [RFC3265]. It is used to indicate the state of the Invite session, such as "new", "pending", "ringing", "active", and "terminated". 8.1.1.9 Expires The Expires header is the same as SIPv2, except it's used in all requests and some responses. It defines how long the session should last without a refresh (i.e., without a re-INVITE). Thus it performs both the previous roles of Expires for RFC 3261-style registrations, and of RFC 4028-style Session-Expires [RFC4028]. 8.1.1.10 Contact The Contact header is a bit different in SIPv4, although its syntax is similar to that in SIPv2. The difference is it MUST NOT include the real IP Address or FQDN of the UAC that originates the request. 8.1.2 Processing Responses All responses in SIPv4 are one of the following: 200, 300, 400, 500, 600, 700. There are no other responses, but just in case: a UAC MUST treat any response in the range 200-299 as a 200, 300-399 as a 300, etc. 8.1.2.1 Processing 300 Responses A 300 response is a redirect, and the UAC SHOULD re-generate the INVITE request (with a new Call-Id and Cseq and tag) to the URI(s) indicated in the Contact header of the 300 response. Since Contact headers don't actually have valid hostname portions, it would end up re-sending the request to the same outbound B2BUA; but the user portion would be new and presumably lead the B2BUA to route it differently. 8.1.2.2 Processing 400 Responses A 400 response basically means the B2BUA or UAS did not understand the request, or failed sending it due to some incompatibility reason specific to the client-server combination. The UAC can retry the request through another B2BUA, if it has another one to use. This is different than SIPv2, because in SIPv2 there were a bunch of 4xx responses which had specific meanings about what was wrong with the request. This was done for the misguided idea that a UAC could change the request and re-send it. That was hardly Kaplan Expires October 1, 2008 [Page 16] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 ever the case, however - the UAC sent the request as it did because it thought that was the right thing, or had no other choice. The SIP layer doesn't implement the Artificial Intelligence system or [RFC3751] which would be required to know what to do with 4xx codes to fix the request. So instead, SIPv4 simply gives the UAC the option to send it elsewhere if it can, or give up trying to send that request. 8.1.2.3 Processing 500 Responses A 500 response means the B2BUA or UAS is generally in trouble, and the UAC shouldn't send it any requests for the time specified in the Expires header in the response, or a really, really long time if there was no Expires header. 8.1.2.4 Processing 600 Responses A 600 response means the UAS or B2BUA has some definitive knowledge that the ultimate resource for that request cannot be reached or doesn't exist - in other words, the UAC shouldn't bother sending that request again. We have no idea how a UAS or B2BUA could have such global knowledge, but it's theoretically possible. 8.1.2.5 Processing 700 Responses If a 700 response is received, the UAC SHOULD follow the SIPv2 digest-challenge mechanism, as if it were a 401/407 response in RFC 3261. The only reason not to is if you don't have valid credentials, or have gotten a 700 response after trying more than three times (i.e., three strikes and you're out). Note this does NOT mean you are in the "700 Club". SIP has its own religion, and you enter it when you get a 200 response, thus it's a "200 Club". Malicious devices MUST NOT attempt the same request again, or attempt to determine the credentials through any means. [Note: Remember, this is a secure protocol.] 9. SIP and SIPSS URIs As stated previously, in SIPv4 the SIP and SIPSS URI's look a lot like SIPv2 URIs, except the user portion MUST be a phone number format rather than an email-style alphabetic name. In particular, when a UAC generates an initial request, it MUST either use an E.164 phone number, with or without a leading "+", or it MUST use at least just digits (for example if local extension dialing, or calling 911/411/110/etc.). No visual separators are allowed, such as the "-" hyphen and parenthesis and such - the UAC MUST strip those if the user entered them before sending the request. Kaplan Expires October 1, 2008 [Page 17] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Because SIP/SIPSS URIs are phone numbers, there is no need for the TEL URI [RFC3966] so it is hereby deprecated. The only UA's which generated them in SIPv2 were PSTN and H.323 gateways anyway - for them, or for any device which does not know what to set for the domain portion, they MAY use a domain of "e164.arpa" in the SIP/SIPSS URI. All URIs MUST NOT use IP Addresses for the host portion, and MUST use FQDNs or domain names. Some SIP/SIPSS URIs cannot reasonably have valid domain names, such as Contact URIs; in such cases the domain portion must be "invalid.com". 10. Header Fields The same header syntax as SIPv2 applies. 10.1. New Headers 10.1.1 Asserted-ID The P-Asserted-Identity header of [RFC3325] is hereby replaced with the Asserted-ID header. [Note: the PAID header was renamed to this AID one, because the customer has not paid yet, and needs help to do so] This header does much the same thing - the home domain inserts it to identify the caller identity, and it's stripped on leaving the trust domain boundary. While primarily intended for privacy use (by exposing the private information in this header which no one is allowed to read), the AID header is also very useful for billing. According to the perennial SIP working group chair, regarding billing in SIPv2: "If you absolutely MUST skin cats, stop trying to use a potato peeler to do the job" [draft-willis-a-way]. However, rigorous studies such as the one at [skin-cat-study] show a potato peeler is actually #5 in the top-ten ways of skinning a cat, with the main caveat being that it is a slow process. Therefore, what's clearly needed is an *electric* potato peeler; and since the AID header is secure, this draft also defines that the header can carry credit- card billing information, billing address, social security number, mother's maiden name, and anything else needed to perform billing. Thus SIPv4 does support billing, to feed the starving children. 10.1.2 Diversion Since everyone used it anyway in SIPv2, this draft hereby standardizes the Diversion header defined in [draft-levy] and deprecates History-Info [RFC4244]. Kaplan Expires October 1, 2008 [Page 18] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 10.1.3 Session-State Session-State is similar to Subscription-State [RFC3265], but for the INVITE session. It defines the current state of the session, using one of the following values: "new", "pending", "ringing", "active", and "terminated". INVITE requests outside of a dialog use the value "new". Re- Invites or responses before the session is fully active use "pending", similar to 183 Progress. Re-Invites or responses before active but while the UAS is ringing use "ringing". Re- Invites or responses when the called party has answered the call (i.e., off-hook), or when the session is fully active use "active". Re-Invites or responses to end a session use "terminated". 10.1.4 Spit-Score This header contains the score of how important the human user of the UAS considers the call, to avoid Spam for Internet Telephony (SPIT) as defined in [RFC5039], or decide whether to send the call to voicemail. The UAC or a B2BUA can insert or change this header value, but it MUST set it to what the human called party will think of the call's importance. The value can either be a signed decimal number in the range -1000.000 to 1000.000, or one of the defined string values of (in order of most-important to least- important): "you-won-lottery", "god", "lesser-gods", "job-offer", "nigerian-money-transfer", "mistress-lover", "spouse", "friend", "children", "relatives", "the-boss", "business", "charity", "political", "spit-spam", "ietf-sip-wg", "wrong-number". 10.2. Other Headers The following headers from SIPv2 and its extensions are supported but changed in SIPv4. 10.2.1 Call-ID The Call-ID header is similar to SIPv2, except it MUST NOT use an IP Address in it. Doing so simply begs for a B2BUA to change it. So don't do that. 10.2.2 Contact The Contact header MUST NOT have the real contact IP Address or FQDN in it. It must instead have a form of a GRUU as described in [gruu], which is simply a cookie user portion and the domain of the user in the host portion. If that doesn't work, then it means the sender intended a "Don't call me, I'll call you" semantic. Kaplan Expires October 1, 2008 [Page 19] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 10.2.3 Identity and Identity-Info The Identity and Identity-Info headers and their use is exactly the same as defined in [RFC4474] and [RFC4916]. In addition, every response using Identity MUST include the headers and sign the response if the request included them. Because every hop is a B2BUA, every hop MUST verify and re-authenticate (re-sign) the requests and responses, if the initial received request has the headers. Every SIPv4 device MUST support this mechanism, but does not have to actually do it. Indeed, actually doing this would be a complete waste of time and CPU and have no real security property, but it will look very secure. 10.3. Deprecated Headers The following headers from SIPv2 are hereby removed in SIPv4, with a brief explanation why: 1. Accept - if a UA doesn't accept some format, then it can just reject a request using it. 2. Accept-Encoding - same as above. 3. Accept-Language - honestly, did anyone ever use this? 4. Alert-Info - there's no 180 response in SIPv4, and putting it in a request is weird. We'll create a content-type if this is needed. 5. Allow - only one method, so it would be quite pointless. 6. Content-Length - without a stream-based transport, and since the SHOUT layer already defines a total message length, we don't need this header. 7. Error-Info - hardly anyone used it in SIPv2. 8. In-Reply-To - same as above. 9. Organization - same as above. 10. Priority - everyone thinks their call is important. 11. Proxy-Authenticate - no proxies, ergo no Proxy-Authenticate. 12. Proxy-Authorization - no proxies, ergo no Proxy-Authorization. 13. Proxy-Require - no proxies, ergo no Proxy-Require. 14. Record-Route - since all UAs and B2BUAs are dialog-stateful, and all requests follow the dialog, a Record-Route is redundant. 15. Reply-To - useless. 16. Require - all SIPv4 devices support everything, and no extensions are allowed. 17. Route - without proxies and every request following local policies or other rules, there's no need for a Route header. 18. Server - none of your business. 19. Subject - this ain't email. 20. Supported - all SIPv4 devices support everything, and no extensions are allowed, so no need for this header. 21. Timestamp - huh? Kaplan Expires October 1, 2008 [Page 20] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 22. Unsupported - like a UA knows what it doesn't support?? In SIPV4, everything is supported. 23. User-Agent - very popular, but none of your business really. 24. Via - since there are no proxies, there's no need for a Via. 25. Warning - too confusing. Any other header defined by any extension to RFC 3261 is hereby deprecated, unless explicitly included elsewhere in this draft. 11. Forking, Knifing and Spooning SIPv4 does NOT support forking of either parallel or serial type. Forking, as shown in Figure 3, was the ability for a proxy to "fork" a request to multiple next-hops, either in parallel, or one at a time, until one of them reaches a target which accepts the request with a successful response. The main use-case for forking was to support people being reachable at multiple UA's, for example one call to their number rings both their cell phone and desk phone. Forking causes all sorts of issues in the real world, such as HERFP noted in [RFC3326], and early-media issues with it noted on [draft-stucker-with-a-fork]. Instead, SIPv4 supports an alternative: knifing. Knifing is the ability for a B2BUA to provide the same benefit of reaching multiple targets, but without forking at a SIP layer. Instead, the B2BUA cuts the call in half (ergo "knife"), as shown in Figure 4. The B2BUA MUST answer the INVITE request with a 200 response, at which point it then originates its own INVITEs, potentially using many of the same contents. The big difference, though, is from that point forward the B2BUA has effectively cut the call in half, and must act as a higher-layer bridge between the multiple dialogs, handle canceling outstanding dialogs, etc. One problem that can happen when knifing a call is that two parallel call requests for the same original call could loop to each other, or a single call can knife more than once back onto itself. For example, suppose Bob and Peter both want to be reached for calls to the other because they run some business and share calls. Alice calls Bob, which gets knifed by B2BUA-1 to Bob and Peter; then a B2BUA-2 at Peter's domain knifes the call to Peter and Bob, which sends one call leg back to B2BUA-1. A loop is created, forming a spoon shape, as shown in Figure 5, ergo "spooning". In SIPv2 this would have been detected either by matching Via branches, or Max-Forwards would have eventually decremented to 0. In SIPv4 there is no Via, and even though Max- Forwards is lower, 42 loops is still undesirable. One could use the Call-ID and tags to detect the loop, but each leg of a knifed call is a separate, new session and thus must use a new Call-ID. Kaplan Expires October 1, 2008 [Page 21] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Therefore, SIPv4 creates a Call-ID header parameter named "callid", which is an identifier of the "call" from a layer above SIP, and thus crosses B2BUA's; as opposed to the Call-ID header value which identifies the SIP session. So when the call is spoon-fed back to a B2BUA that created it, it sees the same callid parameter value and detects the spoon. The B2BUA would then respond with a 400 response. Callid parameters are kept in a table, and thus this detection mechanism is called a table-spoon. +-------+ +--------+ Peter | / +-------+ +-------+ +-------+ +-------+ | Alice +-----------------+ Proxy +----------+ Bob | +-------+ +-------+ +-------+ \ +-------+ +--------+ Mary | +-------+ Figure 3: A SIPv2 fork diagram (deprecated) | | +-------+ +-------+ | + UAC +--------+ Peter | | +-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ | Alice +--------+ UAS + | + UAC +--------+ Bob | +-------+ +-------+ | +-------+ +-------+ | +-------+ +-------+ | + UAC +--------+ Mary | | +-------+ +-------+ | | ^cut on this line Figure 4: A SIPv4 knife diagram (instructions included) +-------+ _,+ Bob +._ ,-' +-------+ `-. +-------+ +----+--+ +--+----+ | Alice +-----------------+ B2BUA | | B2BUA | +-------+ +----+--+ +---+---+ `._ +-------+ _,' `--+ Peter +--' +-------+ Figure 5: A SIPv4 spoon diagram Kaplan Expires October 1, 2008 [Page 22] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 12. Resolution of E.164 NUMbers (RENUM) In order to create SIPv4 requests, the UA needs to determine the E.164 number for a given target, in order to form the To, From and Request-URIs. If the user typed in numbers to call, those numbers are used. However, it is possible, though highly unlikely, that a user may have an email-style alphanumeric SIP URI for the target, such as sip:bob@biloxi.com. A mechanism needs to be available to resolve that URI to an E.164 number: RENUM, which stands for either "Resolution of E.164 NUMbers", or more commonly "Reverse ENUM". RENUM should not be confused with ROMAN, which stands for "Resolution of Mediterranean Agent Numerals", which was used to resolve E.164 numbers to Roman-numeral-based URIs; instead of ROMAN, one can use SPQR ("Simple Procedures for Querying Roman- numerals") for resolving Roman-numerals to SIP URIs, in order to comply with The Roman Standards Process [RFC2551]. [Note: ROMAN should not be confused with ROHAN, which is for Resolution Of Head-set Agent Numbers] RENUM works in a similar fashion as ENUM, as follows: 1. The UA converts the email-style URI to a domain name by inserting periods before and after the "@" separator. Thus "bob@bilox.com" becomes "bob.@.biloxi.com", and "alice.pleasance@atlanta.com" becomes "alice.pleasance.@.atlanta.com". 2. The "@" symbol is replaced with the text string "0x40". Thus "bob.@.biloxi.com" becomes "bob.0x40.biloxi.com". This step is necessary because "@" is not allowed in domain names. 3. The resulting domain name is used in a DNS NAPTR query, eventually finding its way to an authoritative DNS for biloxi.com, which presumably has a subscriber entry for "bob". The DNS server knows the request is for a subscriber because of the "0x40" portion, which presumably does not map to a previous legitimate hostname portion in its domain. 4. The authoritative DNS server responds with an "U2E+sip" service type NAPTR response, with a regex replacement field such as "!sip:.*!sip:12128675309@biloxi.com!" or some such. 5. The UA then performs the regex replacement and voila, the SIP URI is now "sip:12128675309@biloxi.com" for use in SIPv4 requests. This mechanism has the benefits that it scales very well, uses the already deployed DNS infrastructure, and allows domains to list their subscribers without relying on third parties to do so. This should work better than public ENUM, because public ENUM required a common root of all E.164 numbers mapped to SIP URIs, which caused privacy and control issues for service providers. RENUM, Kaplan Expires October 1, 2008 [Page 23] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 on the other hand, leaves it up to the final domains (notably Enterprises) to decide if they want to provide the mapping. Furthermore, it allows people to use email-style URIs to reach phones on the PSTN, where most subscribers currently reside, and thus provides an evolutionary path. (or an intelligent-design path, for those who prefer to think of it that way) Users can even host their own RENUM mappings for their own domains, so that for example Bob can have a fixed email-style URI such as "sip:bob@bobsdomain.com" and change what E.164 number it maps to when he switches service providers without needing to change his SIP URI. Thus it provides a SIP-URI portability capability, similar to number portability in the PSTN. Because RENUM puts control of one's identity in the hands of the users, instead of the ITU, the E.164 number portion in the NAPTR regex replacement field MAY be encrypted using a secret only known to registries authorized by the ITU. This would be achieved by converting the username portion into a "cookie"; however, since this cookie is minted by registries for peanuts, the cookie is known as a "peppermint-patty", as noted in Dan York's security draft [draft-york-peppermint-patty]. Only authorized registries can understand peppermint-patties. 13. Session Description Protocol v2.0 (SDP2) Although SDP has been used by SIP and other protocols for a long time, there are still several issues with it: 1. Video conferencing vendors argue that SDP still does not provide what they need. 2. The ability to truly negotiate based on constrained combinations of capabilities cannot be easily done with SDP, which is really more of an announcement of capabilities than a negotiation. 3. Many people argue that H.245 provides the above and is superior to SDP. At the same time, proponents of SDP point to its simplicity of negotiation and text-based encoding as benefiting interoperability. SIPv4 combines the best of both worlds, to form SDP2. SDP2 is essentially H.245, except it uses the text encoding of the ASN.1 dictionary terms, and defines a simpler master-slave exchange than H.245. Thus it can be read by humans when looking at packet traces, while at the same time satisfying anyone who thinks H.245 is better than legacy SDP, because SDPv2 *is* H.245. Kaplan Expires October 1, 2008 [Page 24] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 SDP2 encoding is quite literally the text representation of the ASN.1 dictionary terms for H.245 content. In other words, the textual symbolic names for objects written in the ASN.1 definition documents are used as identifiers in the SDP2 message itself, instead of using TLV-style or PER binary encoding. The curly- bracket delimiters used in ASN.1 definitions are also used literally in SDP2, to enclose the contents of their object. OID values are encoded in dotted-tree form; numerical/integer values are encoded in their decimal form; Boolean values are encoded with "true" or "false"; and text/string values are encoded within double-quote delimiters. All values appear after an "=" separator between the item descriptor name and its value. Each line is CRLF separated. The following is a partial example SDP2 payload (indentation is for readability but does not exist on the wire): TerminalCapabilitySet { sequenceNumber=1 protocolIdentifier=0.0.8.245.0.8 multiplexCapability { h2250Capability { maximumAudioDelayJitter=60 receiveMultipointCapability { multicastCapability=false multiUniCastConference=false ... } ... } } } 13.1. SDP2 Offer-Answer Model The SDP offer/answer model previously defined in RFC 3264 [RFC3264] is updated slightly by SIPv4. Typically, the initial INVITE has an SDP2 body as the offer if it's for a media-type session, and an SDP2 response in the body of a 200 ok as the answer. Although that is probably the only thing that works most of the time, some people like to gamble by delaying their SDP offer, to learn what the far-end support before answering with their own SDP. Since SIPv4 has only final responses, and no ACK, it does not support delayed offers the same way. Instead, one Kaplan Expires October 1, 2008 [Page 25] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 merely sends an INVITE with no SDP2, and the UAS thus sends its SDP2 offer in a re-INVITE upstream after sending its 200 ok. To avoid possible "glare" conditions, where both sides could send re-INVITE's at the same time, or a game of chicken where the UAS also sends back an offerless re-INVITE, we propose a tie-breaker model. The most common form of tie-breaker known to the authors is RPS [worldrps.com]. If the initial UAC sending the INVITE does not include SDP2, it MUST include an "application/rps" body, with a single literal string in the MIME body of "rock", "paper", or "scissors". The UAS MUST then also include an "application/rps" body in its response if it is a 200 ok, with its chosen literal string choice of the same set. Based on the RPS algorithm defined by [worldrps.com], whichever UA loses MUST send a re-INVITE with its SDP2 body. 14. Network Address Translator (NAT) Traversal SIPv2 made a mistake which ended up taking more pages to fix than it took to document the original SIP specification itself: SIPv2 forgot to account for NATs. And we don't mean this as a knock on SIP, because the entire IETF refused to admit NATs exist. Even today, there is a feeling that IPv6 will get rid of NATs, and that they're a short-term issue. Well, we don't. In fact, we would require NATs for SIPv4 to work, if we could figure out how to make that possible. [Can we?] After thinking about it for a really long time, we realized what keeps breaking protocols across NATs: IP Addresses. Protocols keep sticking IP Addresses (and ports) inside their messages, and then are surprised when the IP Addresses were wrong due to NAT. That, and the whole pinhole/binding issue, such that communication has to start from inside the private side of a NAT going to the public side first, and the pinhole has to be kept open. We have fixed these issues for SIPv4 using several integrated mechanisms: DRINK, FIRE, BRIMSTONE, TWIST, and SHOUT. FIRE is essentially the equivalent replacement for ICE, defining a mechanism for media NAT traversal (which uses BRIMSTONE in place of STUN for connectivity checks); except FIRE is a lot simpler and faster than ICE. TWIST and SHOUT handle SIP NAT traversal, essentially replacing STUN/TURN for SIP and fixing transport issues for SIP-outbound type functionality. LEMON-TWIST does the same for media. DRINK is used to keep NAT pinholes open for media. In the final analysis, a mechanism such as that of legacy SIP with ICE simply melts in the presence of FIRE and BRIMSTONE; SIPv4 is Kaplan Expires October 1, 2008 [Page 26] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 better because it does SIP of DRINK with LEMON TWIST, which should end up being good for SIPPING. [NOTE: SIPv4 works for NAT traversal, but is not guaranteed to work for Firewall traversal - to do so, we recommend using FEP [RFC3093], because it works really well] 14.1. Fast Interoperable Relay Establishment (FIRE) The purpose of FIRE, like it was for ICE, is to figure out how to get SIP-initiated media to work across NATs. In the ICE age, this was done by collecting various candidate media addresses, signaling them in SDP, testing connectivity using STUN checks, selecting a better one, and re-signaling SDP. FIRE works similarly, sort of, but a little faster and simpler, while at the same time being just as successful. FIRE also requires TWIST (Traversal With Internet Server Transport), which is like TURN only different. In particular, for media, FIRE requires a specific variant of TWIST known as "Lightweight Endpoint Media Over NAT TWIST" (a.k.a., LEMON TWIST). FIRE works as follows: 1. The UAC collects all candidate addresses possible, which are all of its local address+port combinations for media. 2. The UAC also picks a few random address+port combinations as potential candidates (you never know if one may work!) 3. The UAC sets one address+port as the active one - this would be the address+port were it not to be behind a NAT or support FIRE or know any better about any of this. 4. The UAC then sends the INVITE with SDP2 with the active and all possible candidates (including the random ones). 5. The B2BUA then performs LEMON TWIST, and modifies the active connection address for media, replacing it with one of its choosing which it will use for relaying media. 6. The UAS receives the B2BUA's INVITE with SDP2, and uses the active connection address for media and DRINK messages. However, it also sends BRIMSTONE messages to the alternate candidates, as well as to a couple random addresses (you never know if one may work!). 7. The UAS sends back a 200 Okey Dokey with SDP2 containing its own candidates. 8. The B2BUA performs LEMON TWIST again (at this point it's called a "Double Shot"), and replaces the active connection info for media in the SDP2 as it passes it on. 9. The UAC gets back the 200 Okey Dokey and sends media to the active connection address/port (namely to the B2BUA), while also sending BRIMSTONE messages to any other candidates in the response, as well as some randomly chosen addresses (you never know if one may work!). Kaplan Expires October 1, 2008 [Page 27] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 10. At this point media works, as it gets relayed through the B2BUA's. But the raining of BRIMSTONE messages down on random and signaled candidate addresses continues until a re-INVITE is received or the call ends. You'll note this is very similar to ICE, except FIRE always ends up using the "relayed" addresses through B2BMA's - any connectivity discovery directly between UAC and UAS for media is purely coincidental, and ignored. What's more, FIRE is faster than ICE because the addressing used for media to begin with is always the final one used, and works, and does not need additional SDP negotiation and STUN connectivity checks to occur. 14.2. Dummy Relay Internet Nat Keepalive (DRINK) The DRINK message is a no-op message sent in the media path to create a NAT binding and keep the NAT binding alive for media. It is effectively a STUN [STUN-bis] message, with a new fixed STUN message type of its own. The contents of this message do not get changed when the server-side reflects the message back to the client, except the source and destination IP addresses and port get swapped at layer 3, obviously. Not changing the STUN message content lets hardware easily do this, and thus will make it likely to be implemented. 14.3. Traversal With Internet Server Transport (TWIST) The general purpose of TWIST is to fix SIP signaling traversal of NATs, thereby obviating the need for [sip-outbound]. TWIST is not just limited to SIP signaling - it handles any form of inline/on- demand NAT traversal fixing. The basic concept of TWIST is born from the religious morale of "do unto others as you would have them do unto you". For TWIST this translates to "send responses to the address that sent requests to you, and send requests from the address that you want responses sent to you". So if you listen on IP Address X and port Y, then you MUST send from address X and port Y. And if you get something from a remote device's IP Address Z and port W, send back to it at address Z and port W. Naturally, this only works when TWIST is in the same device that SIP is running on, and thus at least one UA or B2BUA must be on the public Internet if calls cross NATs. This TWIST-ed system can be a B2BUA provided by a service provider, or it can be any UA running on someone's PC, for example. 14.3.1 Lightweight Endpoint Media Over Network TWIST (LEMON TWIST) The concept of LEMON TWIST, also called "TURN-on-demand", is that the B2BUA's can relay media automatically, without any special signaling other than SIPv4 itself. No TURN allocations, no STUN Kaplan Expires October 1, 2008 [Page 28] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 binding requests, no extra boxes. Instead, a B2BUA which is on the public Internet or on the public side of a NAT will simply modify the media IP Address and port numbers in SDP2, making it a B2BMA. Media will then flow to the B2BMA, which will modify the source and destination IP Address and ports based on what it signaled and received in signaling - i.e., essentially what TURN did in the ICE Age. So this is basically a specific form of TWIST, for media - a TWIST-ed sister to TWIST for SIP. 14.4. Benevolent Random Internet Message Sending to Test Other Network Elements (BRIMSTONE) The BRIMSTONE mechanism is fairly clever. Its purpose is to randomly probe and scan network elements, both to see what's out there and to see if the device being probed will crash when getting BRIMSTONE messages they didn't expect or know anything about. Thus, it is just like sending STUN messages using ICE. In fact, BRIMSTONE is a STUN packet format, but it can be any of the STUN message types. Note that BRIMSTONE messages MUST NOT be responded to; they are not for connectivity checks - they are just used to make it *look* like they are for connectivity checks. 15. SIPv4 Transport (hint: it's UDP) SIPv4 only supports UDP transport. Any other transport MUST NOT be used. The reason for this is clear: no one wants to use another one. There are some technical reasons too, such as: 1. TCP requires a 3-way handshake. (As discussed previously, odd numbers are bad, and 3-way is odd.) 2. TCP provides reliable transport host-to-host, but SIP already has a retransmission mechanism which works end-to-end - the extra TCP ACKs are unnecessary and slow things down. 3. TCP has head-of-line-blocking issues. 4. TCP has timeout and retransmission intervals based on 1970's CPUs and network speeds, and not under control of the application. 5. TCP has congestion control. No one wants their SIP messages delayed - just other people's SIP messages. 6. TCP has a Nagle algorithm. No one wants their SIP messages delayed - just other people's SIP messages. 7. SCTP solves problems no one has, such as multi-homing and multi-streaming, at the expense of complexity. 8. SCTP doesn't work across NATs. 9. Not all OS's have SCTP stacks. But those reasons really don't matter - the market has spoken and UDP has won. So, SIPv4 needs to make UDP work. The real problems with using UDP are: (a) message size cannot exceed 64KB, and (b) Kaplan Expires October 1, 2008 [Page 29] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 fragmentation occurs at the IP layer which doesn't work across all NATs/Firewalls. Problem (a) is not really a problem for SIPv4, because no one should ever send a SIPv4 message bigger than 64KB anyway. SIPv4 is not a file transfer replacement for FTP - that's HTTP's job. But it does need to work across Firewalls/NATs. The reason fragmentation at IP layer doesn't work across NATs is not because it's not a whole application message in one IP packet per se (e.g. TCP does that too) - it's because fragmentation at the IP Layer means the fragments after the first one don't have the UDP header anymore, and thus the entire message needs to be reassembled by the NAT/Firewall to figure out which UDP port pinhole or binding they belong to, which is both a resource burden and attack vector on the NAT. 15.1. SIP Has Only Udp Transport (SHOUT) Based on the requirement outlined in the previous section, a solution is needed in order to solve the fragmentation issue for SIP/UDP. After consultation with the World's leading engineers, we have come up with a radical solution: don't send UDP packets which need to be fragmented; instead, fragment at a layer above UDP. That "layer" is a new one for SIP: the SHOUT layer, which stands for "Sip Has Only Udp Transport (So Handle Its Transport)" [Note: the part in parenthesis is silent, to comply with [RFC4041] which we think should apply to the RAI area as well]. SHOUT is a layer that MUST be used. There are no SIPv4 messages sent directly over UDP. [Editor's note: though that could be made optional -i.e., only if message size > MTU then do SHOUT?] SHOUT sits below SIP (and SCU if it's there) but above UDP, and DTLS if it's there. SHOUT is essentially a STUN message, but with a defined STUN message type for "SIP-DATA", and carries the SIP message inside it. There are three fields before the SIP message (before the "data"): a sequence number, a total length field, and an offset field. The sequence number is incremented by the sender for every new SIP message, but it is not used for ordering - the order of SIP messages does not matter (usually). The sequence number merely allows the receiver to correlate SHOUT fragments so it can reassemble them, by reassembling all SHOUT packets with the same sequence number. The total length is the total length of the SIP message, including bodies; in other words the length of the UDP payload were the SIP message to have been sent directly on UDP without SHOUT. The offset is the offset of this fragment relative to the whole SIP message, similar to the offset field in IP fragments. [Note to implementers: don't learn the lessons of IP fragmentation attacks again; harden your code for bizarre offsets] Kaplan Expires October 1, 2008 [Page 30] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 The operation of SHOUT is very simple. The SIPv4 layer hands a whole SIP message to SHOUT. SHOUT then determines (based on MTU- (IP+UDP+SHOUT)) if it needs to fragment the message. If not, it just increments the sequence number, sets the total length to the size of the SIP message, and the offset to zero. If it needs to be fragmented, then SHOUT breaks apart the SIP message into pieces that fit into the MTU-(IP+UDP+SHOUT) payload. SHOUT increments the sequence number but keeps that number the same for all fragments. It then sets the total length to be the length of the whole SIP message for all fragments, and the offset to the specific payload offset of that fragment, starting at 0. The offset and length are single-byte counts, not multi-byte words. Then the SHOUT layer sends the message to UDP, which is commonly referred to as "SHOUT it out loud", or over DTLS if that is used, commonly referred to as "SHOUT it out softly". The size of the length and offset fields is 4 bytes each, and thus the max SIP message is 4GB. [Note: it is very tempting to make them 2 bytes each and thus make it impossible to send larger than 64KB SIP messages, but we just trust no one would send anything bigger than 64KB because that would be silly - also, this way if a UAC sends a 64KB message and a B2BUA happens to make it grow just slightly over that due to header changes, it still works.] Note that SHOUT works in concert with TWIST, defined earlier, to form a "TWIST and SHOUT" mechanism which dances its way around NATs. 16. SIP Compression Underlayer (SCU) The SCU (pronounced "skew") layer is the compression mechanism for SIPv4, which is optional and sits between SIP and SHOUT. A SIP message is SCU'ed ("skewed") when the UA determines it needs to make messages smaller for specific reasons. SIPv2 used SIGCOMP, which we found to be a rather ironic acronym since it was longer than the acronym of "SIP" itself. One would think the acronym for compression should at least not grow in size from the acronym it is compressing, so we created a new mechanism and called it SCU (spelled "SQ" when compressed). Unlike SIGCOMP, which requires a lot of state synchronization, memory, and exchange of "virtual engine" style function codes, SCU is completely stateless and pre-defined. One can capture a single SIP-SCU message with a sniffer-type device and be able to decode it, which is not true of SIGCOMP. [one could argue that SIGCOMP provides a certain level of security through obfuscation due to Kaplan Expires October 1, 2008 [Page 31] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 this characteristic, but SIPv4 does not need that because it has the SIPSS URI] It should be noted that SIPv4 sometimes has smaller message sizes than SIPv2 to begin with, even without SCU - simply because it has no Via, Record-Route, Route, and other headers. [note: SDP2 may be larger though] Thus users may find they don't even need SCU. Furthermore, we should note the issue SIGCOMP and SCU address is NOT one of bandwidth savings - SIGCOMP was created to make SIP messages smaller, in order to reduce call setup delays due to serialization delays and high bit error rates (BER) of wireless links. [Note: why someone on a low-speed/high-BER wireless link cares about 500ms vs. 2 second call setup times is beyond us - they should want those extra 2 seconds to get that last opportunity to focus on their driving, before they start talking and no longer paying attention to the road ahead] SCU performs a multi-stage compression, as follows starting at the first stage: 1. All CRLF (carriage-return and linefeed combinations) are converted to just CR. The double-CRLF MIME separator is converted to just LF. Considering the average header length is ~64 bytes, we figure this saves 1/64th of the SIP message, or roughly 1.5%. 2. All optional whitespace is removed. We assume this saves another 1% on average. 3. Every occurrence of ";tag=" is converted to ";)", and every occurrence of "SIP/2x2.0" is converted to ":P". This should save about 0.5%, and look really cool. 4. Every header name is converted to its well-known compact form. This should save about 4%. 5. Every IPv6 address encoding is converted to its compact fixed- length form based on [RFC1924], but since no one uses IPv6 (because 6 is more odd than 4), this saves nothing. 6. Each 8-bit byte ASCII (UTF-8) character is translated to a 7- bit byte ASCII character. Only printable characters were allowed previously, essentially, so it will fit into a 127- character size space. Anything that was outside the hex range would be escape encoded. This saves 1/8th, or 12.5%. 7. The entire SIP message is converted to ASN.1 Packed Encoding Rules (PER) binary representation, per an ASN dictionary to be documented elsewhere. SDP2 would also be so encoded, and the ASN.1 definition to do so already exists. We figure this should save around 30% - it would save more but SIP has a lot of plain text values. 8. The entire ASN-encoded SIP message is compressed using DEFLATE, or optionally PPMd. This should provide about a 50% savings. Kaplan Expires October 1, 2008 [Page 32] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 9. The compressed message is put in a "SCU packet", which starts with the letters "Z__" (a upper-case Z and two underscore characters) in the first three bytes of the SCU message, followed by the compressed message binary content. The "Z__" preamble distinguishes the message from a non-SCU SIP message (which starts with "INVITE" or a response number code). We would have made it "ZIP", but using "Z__" avoids filtering by firewalls and servers and such. (try it in email sometime and you'll see this phenomenon yourself!) 10. The SCU packet is sent to the SHOUT layer. To summarize the savings, SCU compression provides: CRLF -> CR = 1.5% Whitespace = 1.0% Sip-scheme = 0.5% Header-name = 4.0% Compact IPv6 = 0.0% 8->7 Bits = 12.5% ASN.1 PER = 30.0% DEFLATE = 50.0% --------------------- Total savings = 99.5% Thus an average 1000 byte SIP message would compress down to a 5 Byte message (not counting the SCU+SHOUT+UDP+IP overhead). Note this is an approximate savings - it will depend on the exact message contents. However it should be clear that SCU is far better than SIGCOMP. Even the acronym is shorter! 17. Secure/MIME/(Royalty-free)/Generation-two (S/MIME/$0/G) Encryption of MIME bodies in SIPv2 was technically possible using S/MIME, but never happened in the real world. In SIPv4, a new S/MIME mechanism called "S/MIME/$0/G", for "Secure / Multipurpose Internet Mail Extension / (Royalty-free) / Generation-two" (pronounced "ess-mime-soggy"). [Note: technically, the mechanism is known as the lower-case "s/mime/$0/g", but since it is the formal name of the mechanism, it is written in all-capitals form here.] S/MIME/$0/G is performed with a Soft-Armor encryption mechanism called ROTn, of ROT26, ROT94, and ROT256. These are based on the well-known ROT13 and ROT47 ROTate-by ("ROT") mechanisms, applicable to the 26 letters of the modern Latin alphabet or the 47 printable characters of ascii, as described in [wiki-rot13]. Because those mechanisms have been found to be easily cracked, the rotation shift size (the "key" size) is doubled for ROTn mechanisms: ROT26 performs ROT13 with a 26 character shift, ROT94 Kaplan Expires October 1, 2008 [Page 33] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 performs ROT47 with a 96 character shift, and ROT256 performs a 256 byte shift for what a ROT128 would do for full 8-bit binary bytes. The advantage of these new ROTn mechanisms is through careful design they can be implemented far more efficiently than their predecessors, while still being reciprocal ciphers, and yet twice as secure because their key size is doubled. If this is still found to be weak in the future, one can implement a 3ROTn (pronounced "triple-rotten") version for 3ROT26, 3ROT94, and 3ROT256, in the same way as 3ROT13 is performed in [draft-3rot13]. The other main advantages of S/MIME/$0/G are the originator does not need to share any keying material with the receiver before- hand, nor even indicate which ROTn mechanism was used. Interestingly, ROTn has the property that the encrypted text appears to be valid, so a Man-in-the-Middle snooper will not even know ROTn is being used - it will think it is viewing cleartext, while all the while it is actually viewing encrypted content, and won't know it is being deceived! All SIPv4 messages sent containing MIME bodies MUST use S/MIME/$0/G, always. 18. Secure Real-time Transport Protocol v2 (SRTP2) SIPv4 has a new secure RTP mechanism replacing SRTP, which is lower cost to implement in the hopes of wider adoption: SRTP2. SRTP2 performs encryption at a higher layer than legacy SRTP: the codec layer. It is built into the codecs themselves. The rationale for this is based on ZRTP and DTLS-SRTP. ZRTP and DTLS- SRTP were key-exchange mechanisms for SRTP, not the actual SRTP mechanism, but their main benefit was that they are a form of CAPTCHA: they are so expensive in terms of CPU or DSP overhead, that it would be cost-prohibitive to intercept call media as a middlebox, and thus only a truly legitimate human (or large-budget government agency) could be on the other end. SRTP2 builds on this concept, because any middle-boxes wanting to terminate or be an SRTP2 relay would need to decode the codecs, which would be expensive. The only way they could justify the cost is if they are also performing transcoding or other media-layer services, in which case SRTP2 is beneficial because it lets those service work. Thus SRTP2 achieves a balanced trade-off of security vs. operability, which should make it more widely deployed than legacy SRTP. This concept is documented in Dan Wing's draft [draft-wing- and-a-prayer]. For SRTP2, the encryption codec is performed using the EKR Encoder ("EKR" is pronounced "ecker", as in Boris Becker). The EKR (Expedited speaKing Rate) Encoder performs obfuscation by increasing the rate of audio speech to one not understandable by humans or machines without decrypting. The sentences and entire Kaplan Expires October 1, 2008 [Page 34] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 conversation is compressed in time, which should also reduce bandwidth for RTP. The EKR encoder has proven to be immune from eavesdropping because even when used at a microphone none of the eavesdroppers could understand it. In order to decrypt the EKR encrypted RTP payload, an "EKR Canceller" must be used, which either tries to expand the encrypted speech phrases into words, or sends back RTCP SSL ("Send Speech sLower") packets inside RTCP Receiver Reports. Note that such SSL requests should include the pause duration and new rate, in a cookie field inside a new RTCP "CHOsen COokie CHannel Identifier Packet" (CHOCOCHIP). Many CHOCOCHIP cookies should be sent, to keep the EKR working during breaks in the session. 19. Message Session Relay Protocol v2 (MSRP2) While SIPv4 has a way to send message-based Instant Messages using an INVITE with the "im" event-package indicator, there is still a need for something that is session-based, similar to what MSRP provides for SIPv2. While it is tempting to simply re-use MSRP as it stands, we recognize MSRP has not been very successful in the marketplace so far. Instead, XMPP has been gaining traction, which we believe has to do with it having been released prior to MSRP. Furthermore, we notice that MSRP has a header and routing model not unlike SIPv2, which added to its complexity. Therefore we feel SIPv4 needs a new version of MSRP: MSRP2. In order to provide a time-to-market boost for MSRP2 implementations, while keeping a similar header and routing model as MSRP, MSRP2 uses a stack most SIPv4 vendors already have: SIPv2. SIPv4 creates an MSRP2 session using an INVITE with a "call" package and an MSRP2 media type in SDP2. [Note: it is up to the ITU to define such a media type encoding for H.245, so SDP2 can use it - that should only take a few years] Once the SDP2 is negotiated, the UAC then opens a TCP "media" connection either through the B2BUA using LEMON TWIST, or directly to the UAS, and each side sends SIPv2 MESSAGE requests inside the TCP connection, containing the message contents being sent. The SIPv2 MESSAGE request would be sent using anonymized SIP To/From header, Via's would be ignored, and MESSAGE has no Contact; thus there would be no IP Addresses to screw up NAT traversal. The benefits of using SIPv2 for MSRP2 are: it is well documented, it provides a justification for all the time and money spent developing SIPv2, there would instantaneously be more MSRP2 endpoints and App-Servers/MSRP2-relays than all of XMPP and the original MSRP combined, and it provides a message exchange model even more complicated than MSRP. The end result: profit, to feed starving children. Kaplan Expires October 1, 2008 [Page 35] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 20. Poison Pills One of the issues with SIPv2 was the splintering of the protocol architecture and use model when it was used by other Standards Development Organizations (SDO's). This must be avoided for SIPv4. To stop it from happening again, SIPv4 has three counter- measures: a normative requirement, a requirement trap, and a patent claim. The normative requirement is as follows: The mechanisms defined in this draft MUST NOT be used or referenced by any standards body the IETF does not like a lot, or used in a way inconsistent with the IETF's world-order view of things. In theory that normative requirement above should stop other SDO's from using SIPv4, because they would not comply with that requirement. However, in case they feel the IETF does like them or they are consistent with its use, we need something even stronger. Therefore we have defined a "requirement trap", as follows: 1. If a standards body other than the IETF uses or references the mechanisms defined in this draft, the following requirement #2 MUST be followed. 2. If a standards body other than the IETF uses or references the mechanisms defined in this draft, the previous requirement #1 MUST NOT be followed. If another SDO uses this draft, this should cause a paradoxical loop which will keep the SDO busy forever. Lastly, in case normative statements are simply ignored or misinterpreted, the last form of defense is monetary threats, based on a patent claim, as follows: the IETF hereby claims patent rights and the IESG may or may not have submitted a patent claim for this mechanism. The IESG will give any manufacturer it feels complies with the spirit of the IETF's vision a free license to implement this possibly-patented technology. For the others: the IESG may or may not sue you. Thus, this finally puts to rest the ownership issue which was previously in doubt - the IETF really does "own" SIPv4. 21. Security Considerations This draft mechanism has no security issues, because it is normatively stated it MUST NOT have any. This is assured by using an extra "S" in "SIPSS", and optionally using DTLS, IPSEC, VLANs, or whatever. From a security perspective, we should note that the Kaplan Expires October 1, 2008 [Page 36] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 extra "S" makes it either twice as secure as "SIPS", or at least plus one. The "S" in "SIPS" from RFC 3261 was infinitely more secure than just "SIP", because "SIP" had no trailing "S"; and as all children know, infinity plus one is bigger than infinity... thus "SIPSS" is definitely more secure than "SIPS". Also, SIPv4 has S/MIME/$0/G as a mandatory to use MIME body encryption mechanism. If a malicious entity is in the path, it MUST also implement [RFC3514]. Furthermore, since it is end-to-end-to-end, the distance between ends should be very short, offering little chance for a Man-in- the-Middle (MitM) to exist. If DTLS is used, the SIPv4 protocol being end-to-end provides very strong protection against eavesdropping, MitM, and other attacks. And for 100% security, the protocol can be disabled and the device with it can be shut down and destroyed, thus providing perfect secrecy, privacy, non- repudiation, etc. Thus we allow the user to decide the level of security he/she/it needs. 22. Benefits of SIPv4 The following issues of SIPv2 were fixed by this draft in SIPv4: 1. Lack of end-to-end deployment - since SIPv4 only has UA's and no proxies, end-to-end is the only deployment possible. There is no middle - there are just a lot of ends. 2. No integrated NAT traversal - SIPv4 has NAT traversal built in. 3. No integrated security - SIPv4 adds an extra "S" for SIPSS, uses SRTP2, S/MIME/$0/G, and mandates security. 4. Too many transports - SIPv4 only supports UDP. 5. Too many RFCs and drafts - SIPv4 mandates this be the only document ever created for it. 6. Too many "Standards Bodies" - SIPv4 has "poison pills" which make it unusable by other organizations. 7. Early media issues - SIPv4 has no early media. Though Dave Oran has noted it may have late signaling. 8. HERFP caused by forking - SIPv4 has no forking; just knifing and spooning. 9. Only Alice and Bob can make phone calls - SIPv4 allows Peter, Paul, and Mary to make calls as well. 10. Lack of "P2P" in the title - SIPv4 has two such terms (overlapped) in "P2P2PSIP". Furthermore, SIPv4 provides benefits in terms of code re-use from SIPv2, while leveraging the best common practices from it. We also note that SIPv4's goal is to feed starving children, which is a worthy benefit unto itself. Kaplan Expires October 1, 2008 [Page 37] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 23. Acknowledgements The authors wish to thank the following people for providing the inspiration for this work: Douglas Adams, Jim Abrahams, David Zucker, Jerry Zucker, The Protocol Barbarian, Theies Geditor, Fluffy Raiad, Jon Koolhatson, Matt Groening, William Hanna, Joseph Barbera, Agnetha Faltskog, Bjorn Ulvaeus, Benny Andersson, and Anni-Frid Lyngstad. Special thanks to Sam Ganesan, Paul Erkilla, Adam Uzelac, Don Troshynski, and Ida N. Nounce for providing feedback and ideas. We apologize if we forgot anyone. 24. IANA Considerations This document makes no requirements of IANA, though IANAL. 25. References 25.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3262] Rosenberg, J., Schulzrinne, H., "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 ... [RFC3320] Price, R., et al, "Signaling Compression (SigComp)", RFC 3320, January 2003. [RFC3711] Baugher, M., et al, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Kaplan Expires October 1, 2008 [Page 38] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4244] Barnes, M., (ed.), "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session Description Protocol", RFC 4566, July 2006. [STUN-bis] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session Traversal Utilities for (NAT) (STUN)", draft-ietf- behave-rfc3489bis-15.txt, February 2008. [draft-wing-and-a-prayer] Wing, D., "Secure RTP v2: 'Mission Accomplished'", a work not in progress. [draft-york-peppermint-patty] York, D. (jabber liaison), Livingood, J. (actual author), "A Form of Attack on Registries: Shockey and Awe", oral draft delivered in SPEERMINT WG, March 2008. [worldrps.com] http://www.worldrps.com. 25.2. Informative References [oed] Simpson, J. (ed.), "Oxford English Dictionary", http://www.oed.com, Oxford University Press, 2008. [RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, April 1996. [RFC2551] Bradner, S., "The Roman Standards Process - Revision III", RFC 2551, April MCMXCIX. (Ironically, MCMXCIX happens to be one of the authors of this draft's vehicle license plate numbers (really)) [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [RFC3093] Gaynor, M., Bradner, S., "Firewall Enhancement Protocol (FEP)", RFC 3093, April 2001. [RFC3325] Jennings, C., Peterson, J., Watson, M., "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Kaplan Expires October 1, 2008 [Page 39] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 [RFC3326] Schulzrinne, H., Oran, D., Camarillo, G., "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 2003. [RFC3751] Bradner, S., "Omniscience Protocol Requirements", RFC 3751, April 2004. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4028] Donovan, S., "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4041] Farrel, A., "Requirements for Morality Sections in Routing Area Drafts", RFC 4041, April 2005. [RFC4474] Peterson, J., Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [RFC4975] Campbell, B., Mahy, R., Jennings, C., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5039] Rosenberg, J., Jennings, C., "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008. [draft-3rot13] Richardson, M., Schneier, B., Kivinen, T., "The use of 3ROT13 in the IPsec Encapsulated Security Payload", http://www.sandelman.ca/SSW/ietf/rfc-3rot13, April 1999. [draft-diversion] Levy, S., Yang, J.R., "Diversion Indication in SIP", draft-levy-sip-diversion-08.txt, August 2004. [draft-stucker-with-a-fork] Stucker, B., "Coping with Early Media in the Session Initiation Protocol (SIP)", draft-stucker- sipping-early-media-coping-03.txt, October 2006. [draft-willis-a-way] Willis, D., "Where There's a Will(is), There's a Way: memoirs from a SIP WG Chair", work in progress - this referenced portion found at http://www.ietf.org/mail- archive/web/sip/current/msg09975.html, at the very end. Kaplan Expires October 1, 2008 [Page 40] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 [gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-15.txt, October 2007. [ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic- ice-129.txt, October 2017. [sip-outbound] Jennings, C., Mahy, R., "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-11.txt, 2007. [skin-cat-study] "This Month's List of Ten: Ten Ways to Skin a Cat", http://www.thestrangetimes.com/Mar07ListofTen.html, March 2007. [turn] Rosenberg, J., Mahy, R., Matthews, P., "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn- 07.txt, February 2008. [wiki-rot13] Rosenzweig, V., et al, "ROT13", http://en.wikipedia.org/wiki/ROT13, March 2008 (latest changes). Authors' Addresses Hadriel Kaplan Spacely Spackets (Via Branch Office) Springfield, USA, Earth Mark-I (mostly harmless) Galactic Sector ZZ9 Plural Z Alpha Email: hkaplan@acmepacket.com Robert Penfield Spacely Spackets (Galactic HQ) Booth XLII, Milliway's Restaurant Magrathea, Soulianis-Rahm System Email: bpenfield@acmepacket.com All errors/corrections MUST be submitted using form 1040X, delivered in person to Galactic Civil Service (Megabrantis cluster), signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters. When traveling to Megabrantis, don't forget your towel. Kaplan Expires October 1, 2008 [Page 41] Internet-Draft SIP Version 4.0: P2P2PSIP April 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires October 1, 2008 [Page 42]