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

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 02 Mar 2006 13:15:08 -0500

Kundan, thanks for your comments.
Please see my comment about the record format inline.

Greg Daley wrote:

>Hi Kundan,
>
>I liked your tech report.
>
>Kundan Singh wrote:
>  
>
>>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).
>>    
>>
>
>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).
>
>
>  
>
>>- 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).
>>    
>>
>
>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.
>  
>
Since the record will be interpreted by SIP layer, your suggestion to 
use the SIP Contact header format sounds reasonable also to me though I 
think the  simple format in the draft won't add much complexity.
We are quite open about the record formats. I just hope the formats are 
simple and flexible enough.

>  
>
>>Also a minor nit: calling it a 'resource record' may be confusing it 
>>with DNS RR.
>>    
>>
>
>Suggestions are welcome.
>
>  
>
>>- 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.
>>    
>>
>
>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.
>
>  
>
>>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).
>>    
>>
>
>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.
>
>  
>
>>- 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...
>>    
>>
>
>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.
>
>  
>
>>- 7: typo: befind=>behind
>>
>>- 11.6: recorrds=>records
>>
>>- 12: as per my record 'Salman [Basset=>Baset]'
>>
>>    
>>
My apologies to Salman.

Thanks.

Eunsoo

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Wed, 08 Mar 2006 17:47:46 +0800

Hello Mr.Shim,
        Can the DHT support content search? I mean the key word which
putted by ON may be not as accurate as those stored in the DHT network.

 
 
Sincerely yours,
Seaward

************************************************************************
***************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!
************************************************************************
*****************

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eunsoo Shim
> Sent: Tuesday, February 28, 2006 7:22 AM
> To: P2P-SIP
> Subject: [p2p-sip] I-D: An Architecture for P2P SIP
> 
> 
> 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-0
0.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.

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 08 Mar 2006 11:55:52 -0500

Hi,

Content search is not a focus of P2P SIP and currently out of scope by 
the proposed charter.
So this list is not a good place to discuss about content search.
Having said that, please let me say a few words about DHT and content 
search.
The basic DHT is not good when the resource name is not known precisely.
But if right keywords can be easily guessed for resources, DHT can be 
used for keyword-based (content) search.
There are a number of literature about how to design content search over 
DHT.
eDonkey's eMule client is using Kademlia, a DHT.
Thanks.

Eunsoo