Subject: [p2p-sip] I-D: An Architecture for P2P SIP

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 27 Feb 2006 18:22:26 -0500

We submitted an I-D that describes an architecture for P2P SIP.
You can get it from the link below until it appears in the IETF I-D 
directory.
We hope this draft can help the architecture and charter discussion in BOF.
Your comments will be appreciated.
Thanks.

Eunsoo

http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p-arch-00.txt

Abstract

   This document describes an architecture for peer-to-peer SIP systems
   in which a separate and independent peer-to-peer overlay layer
   provides a distributed resource placement and search service for SIP.
   It also aims to help identify what should be specified for
   interoperation.

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Mon, 27 Feb 2006 20:08:04 -0500

Hi All,

On a similar note: Henning and I had written a tech report documenting 
our experience with "Using an external DHT as a SIP location service". 
If you are interested, you can read the report at
http://mice.cs.columbia.edu/getTechreport.php?techreportID=388

In particular, it describes using OpenDHT.org for contact management, 
key storage, presence, offline messages and STUN server discovery using 
pseudo code and examples.

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Tue, 28 Feb 2006 11:02:28 +0100

Hello Eunsoo,

I like much this document because it outlines several things the make  
sense and can be achieved.

I personally spent some time in the bootstrap realm, what I end-up  
with is described at:

http://www.ag-projects.com/doc/SIPThor_UsingDNSforDHTlookup.txt

Regards,
Adrian

On Feb 28, 2006, at 12:22 AM, Eunsoo Shim wrote:

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Tue, 28 Feb 2006 11:07:28 +0100

http://www.ag-projects.com/docs/SIPThor_UsingDNSforDHTlookup.txt

On Feb 28, 2006, at 11:02 AM, Adrian Georgescu wrote:

> Hello Eunsoo,
>
> I like much this document because it outlines several things the  
> make sense and can be achieved.
>

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Tue, 28 Feb 2006 14:17:08 -0500

Some comments and feedback:

- Seems like you propose to do P2P lookup first and then fall back to 
DNS (RFC3263). But since P2P lookup is slower, the reverse is probably 
more desirable, i.e., if DNS SRV/NAPTR exists, try that first. (or for 
INVITE do parallel forking to DNS and P2P destinations).

- sec 8: regarding the format of records: It is probably better to reuse 
the existing SIP Contact header format. Since implementations will do 
SIP parsing anyway, and having multiple formats is just more work for 
translating from one to another. Thus instead of splitting IP, port, 
transport, etc., e.g., just put 
<sip:user at 178.14.234.21:5060;transport=udp> if it supports only UDP, and 
ignore transport= param if it supports both. Multiple ports can be 
specified using multiple contacts. (appendix A of my tech report 
http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 has 
another example of the data format for P2P-SIP).

Also a minor nit: calling it a 'resource record' may be confusing it 
with DNS RR.

- I am not quite clear about the purpose of 'login server'. Is this 
contacted every time the phone is started (like Skype's login server), 
in which case it is clearly not desirable unless it can be made p2p or 
distributed. Or is it like a certifying authority that is contacted only 
(once?) for issuing or renewing the certificate.

Minor corrections:

- page 15: typo: ...peers may be able [to] use...

- sec 5.3: I think we should add TLS (either separately or same line as 
TCP).

- 5.4: incomplete sentence 'After the association'

- 5.4: '...credentials [MAY=>MUST] be needed...' I think. Similarly, 
'... the ON [will wish to=>MUST] authenticate the SN...

- 7: typo: befind=>behind

- 11.6: recorrds=>records

- 12: as per my record 'Salman [Basset=>Baset]'

Regards.

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Tue, 28 Feb 2006 14:26:22 -0500

Hi all,

Similar to this DNS idea, I had seen a post on opendht mailing list 
sometime ago:

Posted by Sean Rhea  srhea at MIT.EDU
Tue, 31 Jan 2006 16:10:34 -0500

I'm pleased to announce that there is now a DNS-based alternative.
Just lookup the hostname opendht.nyuld.net, and it will return two
proximal OpenDHT servers.

For example:

    $ dig +short opendht.nyuld.net
    opendht.803b43c9.oasis.nyuld.net.
    128.59.67.200
    128.119.247.211

As you might guess from the hostname, this service is being provided
by Mike Freedman's new OASIS service, soon to be published in NSDI'06:

    http://www.usenix.org/events/nsdi06/prelim.html

Enjoy, and thank Mike for help making this happen.

Sean
--

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 28 Feb 2006 16:19:49 -0500

Hi Kundan,

I liked your tech report.

> INVITE do parallel forking to DNS and P2P destinations).

I take your point, although there may be other reasons to try
P2P first rather than go for CS/SIP related DNS infrastructure
(for example, cost, or more accurate local lookup information).

> another example of the data format for P2P-SIP).

Something very explicitly stated in the draft is the fact that we
want to have a different (and possibly quite distinct) protocol layer
undertaking the protocol operations for the P2P lookups.

We may be able to make use of existing formats so long as this
doesn't cause confusion about which components belong to which
layer.

> Also a minor nit: calling it a 'resource record' may be confusing it 

Suggestions are welcome.

> (once?) for issuing or renewing the certificate.

It may yet be too early to say, but may have some preference not
to contact a server each time.  I'm actually not sure what
other systems do right now with regard to login (few people are).

Some people may think it is valuable to explicitly authorize
participants to join the network.

> - sec 5.3: I think we should add TLS (either separately or same line as 

UDP and TCP can both use TLS/dTLS.  We describe transport security
in the security considerations section.

So we're not saying "in the clear" TCP.

Once again, it may be too early to say.

> '... the ON [will wish to=>MUST] authenticate the SN...

We need to go through these requirements individually.
Within the authors team we had these discussions, and
made the terms flexible for the initial description.

> - 12: as per my record 'Salman [Basset=>Baset]'

Thanks

Greg.