Presence and IntComm WG

[Jamey Hicks <>]

Jeremy George wrote:

> This posting isn't directly on target for PIC but may interest
> folks anyway. P2P SIP may not compete with proxy-based SIP so much as
> complement it. See the use cases noted below. How do we blend the two?
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.

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).

It's also possible that an ad-hoc collection of communicating nodes 
could have one or more nodes choose to be a registrar for the group and 
to respond to messages sent to 224.0.1.75.

I would actually expect the P2P mechanism used for a global P2P 
directory service to be different than that used by a PAN. A global 
service needs to be able to distribute directory information and query 
processing across the internet while a PAN only needs to keep track of a 
small number (say 5-20) devices.

I think this kind of hangs together. SIP UA's send REGISTER messages to 
multicast address 224.0.1.75. If they get one or more OK's, then there 
is a SIP server, which may be used as an outbound proxy as a "default 
route" for sending other SIP messages.

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.

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.

How does a node discover that it is in a PAN? If it has a preconfigured 
IP address, it is probably not in a PAN. If it sends DHCP requests and 
gets no responses to DHCP, it is likely to be in a PAN. In this case, it 
should use zeroconf IP addresses. In a PAN with ad-hoc infrastructure, 
the node may receive an address via DHCP but not a DNS server, so it 
would not be able to use DNS A or SRV lookups to determine the SIP 
registrar address, so it should use the multicast address as described 
above.

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.

Jamey