Presence and IntComm WG

[Jeremy George <>]

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?

> It seems to me that the obvious way to blend the two is to have SIP UA's that 
> support both centralized SIP registrars and P2P SIP directories. I suppose 
> some UA's would only need to support one or the other, but that would limit 
> their utility.

  Yes, I don't see how it could work without the UAs being involved.

> 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?

  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?

> 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?

> 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?

- Jeremy