Presence and IntComm WG

[Jamey Hicks <>]

Jeremy George wrote:

> Jamey,
>
> Thanks for responding.
>
> I am sooo glad that you are in the group. Not much is obvious to
> me in this. In the case of a PAN it would seem that the UA (maybe on
> a PDA) would need to communicate locally via P2P but still be able to
> REGISTER and communicate via centralized proxy server for campus-related
> services (i.e. gatewaying to the PSTN). So, don't at least some
> devices in the PAN need to be dual REGISTERd?

There are probably many configurations of the network, depending on 
whether the PAN is totally isolated or connected via a node with an 
internet connection of some sort. Here are some examples:
1) isolated PAN, e.g., internet2 PIC meeting on island with no landline, 
cellular, or satellite connection.
2) emergency response PAN with satellite uplink in a truck
3) home PAN with DSL or cable modem internet connection

One of the questions is whether the scope of names is local or global. 
Another whether connectivity is local or global.

A UA might have multiple registrations, perhaps because it is 
registering a local P2P name and a global name. On an isolated PAN, 
there will only be local naming and routing. A PAN with an uplink might 
have global routing via a SIP proxy with an uplink or internet connection.

For the purposes of this discussion, if a PAN has global connectivity 
and routing, it's just a piece of the internet and behaves just like any 
other piece of the internet. The SIP registration process, whether 
centralized, distributed P2P or local P2P, is about naming and 
rendezvous. The naming component is that we assume that two instance of 
the same name, e.g., , refer to the same user, while 
two different names refer to different people or to one person via 
multiple services. More importantly, we would like to defend against two 
different people using the same name. But I think that's another 
discussion.

The rendezvous component lets us use a local or global name in a way 
that is to some extent independent of where the user agent attaches to 
the network. So the particularly important component for this discussion 
is name resolution: finding the IP addresses associated with a SIP URL.

One other aspect that is important to this discussion is that SIP 
registrations are soft state. It's not like a filesystem where if a disk 
disappears you lose data. A cold restart of a registrar temporarily 
loses the name->contact binding, but within one full registration cycle 
all the bindings get reconstructed.

> > The P2P SIP directory function could actually be a separate program 
> > running on the same node, and it could be discovered by at least some 
> > of the same mechanisms used to find centralized registrars, e.g., 
> > multicast to the "all SIP servers" address (224.0.1.75).
>
>
> My understanding is that P2P SIP uses a DHT running on one or more
> supernodes. Is that what you are referring to as a P2P directory?

I've been using P2P as a more generic term, because we can do P2P 
without using a DHT. A DHT is not warranted if there are a small 
collection of name bindings to keep track of, e.g., the members of a 
first responder team operating within radio range of each other. In that 
example, a pure P2P system where each UA maintains the name->contact 
binding for all other members of the team might make sense. I outlined 
three main approaches for maintaining the registration database: 
centralized registrars, DHT, and pure P2P, each of which has advantages 
in different situations. Flexible UA's will support more than one of 
these approaches so that they can be deployed in whatever setting you have.

> What would happen if four people are sitting at a table and they turn
> on their PDAs? Do they form a super-PAN? What happens when lunch is
> over and they separate?
A PDA all by itself is one node, not a PAN. 4 PDA's together could form 
a PAN plus their associated wireless headsets and keyboards could form 
some sort of super PAN. Again, there are separate issues of routing and 
naming. They might each have their own local namespaces so that the PDA 
can talk to its associated peripherals. They might have an ad-hoc shared 
namespace so that I can communicate with you via our PDAs.

> > If there are no responses, then there are no nodes acting as SIP 
> > registrars. In that case, it might be a PAN configuration, and so the 
> > SIP UA listens on 224.0.1.75 to build up a local directory of other 
> > UA's in the PAN. I would argue that the SIP UA should be able to use 
> > 224.0.1.75 as a default route to reach other UAs in the PAN, 
> > otherwise it has to wait on average half a registration cycle to 
> > discover a particular user's contact address.
>
>
> Does a PDA needing to communicate with both PAN and globally via
> centralized server imply multihoming?
Not in the usual sense of being connected to multiple service providers, 
but yes in terms of having a node with multiple network interfaces 
somewhere in the PAN.

> > In the case of ad-hoc infrastructure, the designated or volunteer 
> > registrars listen on 224.0.1.75, listen to and respond to REGISTER 
> > messages and act as proxy for the group of nodes in the PAN. The 
> > advantage of ad-hoc infrastructure is that non-registrars can leave 
> > their radios off more of the time, preserving battery life. Remember 
> > that for short-range radios, receiving uses more power and energy 
> > than transmitting.
>
>
> This sounds more like the Skype model of single supernode. I didn't
> know that receiving used more power but I absolutely take your word 
> for it.
> Maybe over drinks sometime you can explain it.
>
> > I'd have to reread the draft on the global P2P registration mechanism 
> > to see exactly where it fits in, but it does seem like there is a 
> > reasonable way for a UA to operate in various levels of 
> > infrastructure and to discover what mechanisms are in use.
>
>
> I don't doubt that there's a way, I just need it explained to me :)
>
> Does this all get a little harder in the emergency responder case where
> the notion of PAN may expand to a small group area network? How would
> trust work?
I think trust is related to how well we can be sure that the user 
associated with a UA registering a particular SIP URL is the person we 
think it is. And there are organizational, hierarchical and peer-to-peer 
mechanisms for assuring that we are in fact communicating with who we 
think we are communicating with, e.g., certificates, PGP keychains. I 
would have to think about this piece a bit more to give a cohesive 
answer on it.

Has this been helpful at least on the issues of 
centralized/distributed/P2P/localized ways of resolving names to 
contacts? Do you still have questions on this?

Jamey