[p2p-sip] My notes on draft-willis-p2psip-concepts-01

Spencer Dawkins spencer at mcsr-labs.org
Thu Sep 7 15:58:00 EDT 2006

I'm trying to get through this document at several levels - I hope these 
comments are coherent (and helpful).

Summary - the document is really a good start, even though I have lots of 
notes and suggestions. Thanks for the hard work.


Spencer Dawkins

High-level comments ...

- in general, I'd like to tighten up the terminology that we use. There are 
terms with four additional "short forms" listed. This seems unnecessarily 
confusing. It is OK to have a short form, but can we deprecate at least some 
of the choices?

- as a follow-on, it's not clear to me how much of the terminology is P2PSIP 
and how much is P2P in general. For example, is there anything special about 
a "P2PSIP Overlay Key", compared to an "overlay key"?

- Figure 1 seems confused on whether the UA/Peers behind the NATs are part 
of the overlay or not - I think I can draw the lines more clearly (shown 
below), assuming that they ARE part of the overlay.

- Figure 1 is also trying to do more than you can do in ASCII art (at least 
I think so) - the dotted lines either mean (a) logical connectivity in the 
overlay, (b) physical connectivity through the NATs, or (c) a SIP call. I 
doubled the lines for the overlay topology, but left the SIP calls in and 
don't like the result. If people agree, I can do ASCII art for (a) and (c), 
as two figures.

- I'm very confused about how both clients and peers can be "endpoints". For 
one thing, I'm not sure how "endpoint-to-endpoint trust" works. I suspect 
that this is conflating P2P endpoints (peers) with SIP endpoints (either a 
UA-peer or a UA-client). If you guys understand this perfectly, please keep 

- I'm somewhat confused about how we can talk about P2PSIP peers and clients 
without talking about something like a P2PSIP Overlay Server (see comments 

Detailed comments ...

2.  Definitions

   P2PSIP Overlay User Agent:  A SIP user agent that is coupled to a
      P2PSIP Overlay Peer or P2PSIP Overlay Client, such that the peer
      or client can assist the UA with registration (storage of a route
      to users of the UA) and/or routing of requests using the P2PSIP
      Overlay.  A P2PSIP Overlay SUer Agent differs from a conventional


      SIP user agent in that it is coupled directly to a P2PSIP Overlay
      Peer or P2PSIP Overlay Client, and can therefore directly interact
      with a P2PSIP Overlay, which a conventional SIP UA cannot do.
      P2PSIP Overlay User Agents are presumed to have no distinguished
      name or identifier.  Short forms: overlay UA, P2PSIP UA.

   P2PSIP Overlay Bootstrap Server:  A network node used by P2PSIP
      Overlay Peers or Clients who are attempting to enter to locate an
      entry into the P2P Overlay Network.  It may return an entry point
      (address of a Peer) to the P2PSIP Overlay or act as one itself.
      This should be a quasi-stable and well known host, located using a
      configuration or discovered via , DNS, broadcast, or other
      mechanism.  Example: a P2PSIP Overlay Peer that reboots and has no
      knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to
      find other peers in the P2P Overlay Network and establish P2PSIP
      Overlay Peer Insertion.  (Note: An overlay peer might or might not
      provide this functionality).  Short forms: bootstrap server, boot

These short forms seem very likely to conflict with lower-layer usage of the 
same terms, where "bootstrap server" and "boot server" have a 
well-understood usage. "Overlay bootstrap server" as short form?

3.  Discussion

3.1.  What Kinds of P2PSIP Overlay Peers and Clients Might Exist?

   3.  Gateway: a peer or client that converts from P2PSIP to some other
       protocol, such as PSTN.

"PSTN" should be expanded on first use. It is expanded, but not on first 

   4.  Redirector or Location Server: a peer or client that, given a SIP

Is this a "SIP INVITE", or something else? looks like a cut and paste error.

       (or other SIP request) to a P2PSIP overlay resource identifier,
       returns the route to a resource in a 302 or 305 response.

3.2.  Reference Model

Note - this is my redrawn picture, with changes on the left...

    --------        |N|        | Gateway |
    |      |========|A|========|   Peer  |==============
    |  UA  |        |T|        |         |             ||Client Protocol
    | Peer |                   -----------             ||  GET/PUT
    |  C   |                                           ||  |
    --------                                           ||  |   \__/
       ||                                              ||  v   /  \
      |NAT|                                            ||---- / UA \
       ||                       P2PSIP Overlay         ||    /Client\
       ||                                              ||    |______|
       ||                        Route Data            ||        ^
    --------      --------                             ||        |
    |      | |N|  |      |                             ||        |
    |  UA  |=|A|==|  UA  |                             ||        |
    | Peer | |T|  | Peer |                             ||        |
    |  D   |      |  E   |                             ||        |
    --------      --------                             ||        |SIP
        Peer Protocol ||  ---------        ---------   ||        |
                      ||  |       |        |       |   ||        |
                      ====| Proxy |========| Redir |====         |
                          | Peer  |        | Peer  |             |
                          |       |        |       |             |
                          ---------        ----------            |
                         /                         \            /
                        /                           \          /
                 \__/  / SIP                     SIP \  \__/  /
                  /\  /                               \  /\  /
                 /  \/                                 \/  \/
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

   Figure: Reference Model

   Here, the large rectangle represents the P2PSIP Overlay and its
   associated routing data.  Around the periphery of the P2PSIP Overlay
   rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN
   gateway, a user-agent, a proxy, and a redirector.  To the left we
   have two UA peers are behind network address translator.  On the
   right side, we have a P2PSIP Overlay "UA client", which uses the
   P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay.
   Below, we have conventional SIP UA "A", which has used SIP to
   interact with the Proxy Peer and establish a dialog with the UA peer,

There were three unnamed "UA peers" on the diagram. I'm not sure which one 
you were talking about, and I couldn't figure that out from the diagram (see 
previous whining about combining logical network topology and call paths on 
one diagram) but I at least named them in the diagram, so you can call one 
out in the text.

   and SIP UA "B" which has been redirected by the Redirect Peer and set
   up a dialog with the UA Client.  Note that the Proxy Peer and the UA
   Peer interact using the P2PSIP Overlay Peer Protocol, which is also
   presumably used on the keepalive links between the UA Peers and their

"keepalive links" hasn't been defined, and I'm not happy with the term. Are 
these any more than "logical links", in this context?


3.3.  Conceptual Outline of Operations

3.3.1.  Enrolling and Inserting an P2PSIP Overlay Peer

   Peers are the full-function "routing and storage" nodes of a P2PSIP
   Overlay.  When a new peer is first created, it must enroll in the
   P2PSIP Overlay.  We currently have no defined mechanism for this (do
   we need one?), but we know that once the process is complete, the new

I think this is required for the ad hoc scenarios, isn't it?

   peer will have at least a P2PSIP Overlay Peer Key and a set of

   After enrollment, each time the peer connects to the overlay, it must
   insert itself.  We don't have a defined protocol and process for
   this, and assume we need one.  Presumably the inserting peer connects

I agree that we need one.

   to one or more existing peers (possibly with the aid of a bootstrap
   server) presents its credentials, and ends up connected to the
   overlay, with some knowledge of neighbors (successor, precursor,
   finger tables, or whatever the distribution mechanism defines) and is
   able to store data on behalf of and route requests to other nodes in
   the P2PSIP overlay.

3.3.2.  More on The Difference Between a Peer, Client, and User Agent

   P2PSIP Overlay Peers directly interact with and contain the routing
   and storage fabric of the overlay.  P2PSIP Overlay Clients just use
   the routing and storage facilities provided by the peers.  The peers
   speak the P2PSIP Overlay Peer Protocol, which presumably has a full
   range of expressivity for the routing and storage facilities of the

"expressivity" is a great word. Is it defined anywhere? ;-)

   overlay.  Clients speak the P2PSIP Overlay Client protocol, which is
   presumably a subset of the peer protocol, and is limited to storage
   insertion (put), storage retrieval (get), and message routing (send).

   Some peers and some clients may be coupled to SIP user agents, making
   them P2PSIP Overlay User Agents capable of both sending and receiving
   conventional SIP messages (as per a SIP UA) using conventional SIP
   resolution procedures and of using the resolution facilities provided
   by the overlay

(missing period after this sentence)

3.3.3.  Enrolling a User and Inserting a P2PSIP Overlay User Agent

   To get started, users must be enrolled in the overlay.  We do not
   have a process or protocol for this, nor are we certain we need a
   standardized mechanism.  We presume that after enrollment, the user
   has a distinguished name within the overlay (example:
   sip:bob at example.com) and a set of credentials useful for
   authenticating its usage of the distinguished name.  One possible
   mechanism for these credentials would be an x.509 certificate.  It
   might also be possible to use a PGP key, a password, or some other
   mechanism.  Presumably following enrollment, the user is also
   equipped with the information needed to connect to the overlay, such
   as the address of a bootstrap server.  Whether this startup
   information is delivered as a part of enrollment of through some
   separate configuration process remains an open question.

I would like to define this, but am concerned that the choice may differ 
per-overlay. Do others agree?

3.3.4.  Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP
        Overlay Client UA

   Assume we have two users, Alice and Bob, who have successfully
   enrolled and inserted themselves into a P2PSIP Overlay using clients.
   Alice wants to call Bob, and enters Bob's user identity (AOR) into
   her client.  Alice's client does not have current knowledge of a
   route-set to Bob's client(s), so it needs to discover one.  Alice's

I was confused here. This text doesn't point anywhere for "it needs to 
discover one", so the reader is left to assume that "Alice's Client then 
does a GET operation on Bob's identity" is how that discovery happens, but 
"then does a GET" sounds like it happens AFTER discovering a route-set. If 
this is how discovery happens, please remove "then", and maybe even go to 
"it needs to discover one by doing a GET operation on Bob's identity".

   Client then does a GET operation on Bob's identity, using a
   previously-discovered peer, or using whatever procedures are needed
   (such as RFC 3263, a bootstrap server, etc.) to find a peer.  Alice's
   client send the GET request to the selected peer.

3.3.5.  Bootstrapping

   If a client or peer is just starting up and has no knowledge of how
   to reach the other nodes of the overlay, it may exercise a bootstrap
   server to find one.  Presumably it discovers the bootstrap server by
   some mechanism such as a DNS lookup, multicast, broadcast or
   configuration, then queries the bootstrap server and receives an
   address for a peer or set of peers that can be used to reach the
   overlay.  Ideally, these target peers will be selected from a
   relatively large pool of peers that are currently online and

This last sentence seems awfully use case-specific, doesn't it?

   After discovering the address of a peer, the behavior of the starting
   node will vary depending on whether it is intending to be a peer or a

Ouch - if I have a peer, I would think that I'm a peer, too. Is the client 
actually discovering something like a "P2PSIP Overlay Server"?

   client.  If it is intending to be a peer, it goes into the P2PSIP
   Overlay Peer Insertion process, at the conclusion of which it is
   actively participating in the target overlay as a peer and is capable
   of routing requests and storing records on behalf of the P2PSIP
   overlay.  If it is intending to be a client, it does not bother with
   insertion, but merely contacts the discovered peer in order to use
   the overlay.

4.  Questions

4.4.  Universal Routing:

   Do all P2PSIP Overlay Peers route requests?  How about clients?

I thought this was one of the differences between peers and clients. If it's 
not, what's the difference?

4.9.  Cryptotransparency

   When forwarding requests, are the bodies of the requests visible to
   peers?  If so, this creates substantial security problems that the
   deployers of conventional SIP have been willing to mostly ignore.
   Can we make peers cryptotransparent (like HTTP proxies) when security
   is requested?

I believe this question is key when we discuss what an endpoint is (see 
previous comments on whether clients are endpoints).

4.13.  Bootstrapping

   We know that sometimes peers or clients will start up without
   knowledge of how to find a peer for insertion.  Do we need to define
   a bootstrap mechanism or mechanisms?  Do we need to define supporting

I believe the answer to both of these is "yes" to support anything like ad 
hoc use cases.

4.15.  Overlapping Domains

   If the P2PSIP Overlay User Identifier is not scoped to a single DNS
   domain, this would appear to allow nodes from two or more apparent
   domains to share a single P2PSIP Overlay.  What, if anything, do we
   need to say about this mode of operation?

If a peer can locate an appropriate overlay AND provide appropriate 
credentials, what would prevent us from supporting this?

4.16.  Hybrid Domains

   It appears possible to have some hosts within a domain using
   conventional SIP and some using P2PSIP.  This potentially raises a
   number of questions: 1) What should happen if we want to run a P2PSIP
   overlay in an existing SIP domain? 2) Do the existing redir/proxy
   servers need to be coupled with a peer layer? 3) When would an
   overlay peer want to discover them as opposed to looking in the
   overlay? 4) Is better not to run conventional SIP with overlay SIP?
   5) When conventional and P2PSIP are run together, shall the existing
   redir servers keep their local databases or switch to the overlay

We've had some discussion on-list here about whether I have the same AOR in 
conventional SIP and P2PSIP overlays or not. Did we converge?

4.17.  Admissions Control

   What do we need to say about admissions control with respect to the
   enrollment of peers and users?  Do we need to discuss per-call
   admissions control in a P2P environment?

I can imagine admissions control for enrollment, but I'm having a hard time 
imagining per-call admissions control in a decentralized P2P overlay - or 
was this the point of the question? 

More information about the P2p-sip mailing list