[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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 <sip:17815551212@biloxi.com>
   From: Alice <sip:12128675309@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e-667102223144;callid=VENUS-1234
   CSeq: 314159 INVITE
   Contact: <sip:12128675309;instance=002ewwef78327446@invalid.com>
   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 "<sip:" is converted to "(:", every
       occurrence of "<sipss:" is converted to "<:", 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/