Subject: [p2p-sip] Requirements Explosion

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 11 Jan 2006 15:52:44 -0500

Please let me try to supplement the comments about 'point-to-point SIP 
stuff'.

I seems we need a document about the different P2P SIP design approaches 
so that we can synchronize our discussion in the mailing list more 
efficiently.
I will try to prepare the document as soon as possible. Meanwhile, I'd 
like to encourage people to review the presentation I gave in Vancouver 
(http://www.p2psip.org/ietf64.php  Presentation on comparison of pure 
SIP vs DHT based solutions 
<http://www.p2psip.org/ietf-64/IETF64_P2PSIP_AdHoc_SIP_or_DHT_Shim.ppt>). 
Kundan's email describes what needs to be done if we follow the DHT 
based approach (or External DHT approach) (Obviously we need to unify 
the term to call the approach).

Please let me try to explain or reiterate some points here.

- If we follow the DHT based approach, the SIP call control procedures 
are independent of DHT maintenance (join/leave) and resource lookup and 
placement. In an extreme, nothing has to be changed in the SIP messages. 
To realize P2P SIP (or P2P style SIP-based Internet telephony, IM, etc), 
we need to define three things in this approach: a protocol for DHT 
maintenance and resource lookup/placement, resources types and their 
data formats for the resources to be placed in the P2P overlay network, 
and the rules to generate the resource ID given a resource type and its 
data format. Once the resource ID is set, the underling DHT determines 
where to place the resource and how to look it up.

A most important resource (data) is the user location (mapping of URI to 
IP address). For a basic one-to-one call setup without NAT/FW traversal, 
the user location is all we need to place in the overlay network and 
lookup. It is the same whether the call is audio-only or audio/video 
together.
For Presence, we need a format for presence data. A peer storing 
presence data of another peer will behave as a presence server.

More advanced or complex session control procedures may need more work 
for P2P style operation.
For conferencing, we can have some choices: whether we will make a peer 
play a role of a rendezvous point or design a more distributed 
operation. If a peer becomes a rendezvous point, XCON will work almost 
as it is on top of the P2P overlay network. If we want a more 
distributed conferencing control, it will become a topic on its own. 
Probably it is not in scope of the future P2P SIP WG.

As you can see, the protocol(s) for DHT maintenance and resource 
lookup/placement is independent of SIP call control procedures, 
services, and resource types. Once the protocol is well designed, we can 
enhance the services/features of P2P SIP step by step without changing 
the protocol. So the point made by some people, including Kundan, in my 
understanding, is that we should start with a limited set of SIP 
features and design the protocol for DHT maintenance and resource 
lookup/placement and a limited set of resource types (and formats) 
required for the feauters. By doing this, I would say we will achieve 
the most important piece(s) for P2P SIP. In this sense, whether we cover 
any specific method or header field or an option in various RFCs is not 
important in the beginning.

This does not mean we don't care about supporting all kinds of advanced 
SIP features in P2P SIP domain. I believe no one disregards the 
importance of interoperation between P2P SIP domain and client-server 
SIP domain (and even PSTN).

I guess many RFCs related to SIP won't require any new data type/format 
for SIP operation in P2P fashion. But eventually every single SIP 
feature should be checked whether it requires a new data type/format to 
be placed in the P2P overlay network or even a new call control 
procedure for P2P SIP, if we want to make sure all the SIP features 
described in every SIP related RFC can be used in P2P SIP domain. Again, 
what has been suggested is that we focus on simple and widely used 
features first and worry about others later (in ordely fashion as David 
Barret described).

- If we follow the other design approach where DHT maintenance and 
resource lookup/placement are integrated tightly with existing SIP 
procedures and messages, the design work becomes less modular. In this 
approach, it is actually more important to select some of the SIP 
features we want support with P2P SIP in the beginning. As we move 
forward to support more and more SIP features in P2P SIP domain, it is 
likely that we will be doing still lots of work everytime we add a new 
SIP feature into P2P SIP domain because of poor modularity of the design.

So could we agree on a small set of SIP features as our stating point?

Regards,

Eunsoo

//
Drage, Keith (Keith) wrote:

>I'm afraid I have totally lost the purpose of this point-to-point SIP stuff - or rather I think some of the other members of this list have.
>
>If it is going to be called SIP, then all entities must at least follow some basic SIP compatibility rules. I assume also that SIP methods and headers that normally operate between user agents will still operate between user agents. It should only be protocol that is currently impacted by stuff in the middle that should in any way be impacted by the scope of this work.
>
>So maybe can I propose that SIP p2p supports all SIP methods and headers that normally operate only on a UA to UA basis. If we agree that, then we automatically support 90% of all the SIP RFCs that exist out there, including presence, IM and video. 
>
>P2P SIP should only impact the protocol elements that deal with making sure that end-to-end stuff happens.
>
>Thus while I might expect that something like Path or Service-Route will not work, or anything based on "trust domains", I would like to be confident that something like SUBSCRIBE or Replaces does.
>
>If people really want to build something that doesn't do that, then surely you need to change the title of the list, as it is no longer SIP - and we will see where the IETF stand in terms of inventing a totally new VOIP protocol.
>
>Remember, in Vancouver, I believe we were trying to address something that could be done by an IETF group, the discussion I have seen over the last few days seems to be determined to consign all the work to IRTF.
>
>regards
>
>Keith
>
>  
>
>>-----Original Message-----
>>From: p2p-sip-bounces at cs.columbia.edu
>>[mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim
>>Sent: 11 January 2006 18:42
>>To: henry at pulver.com
>>Cc: p2p-sip at cs.columbia.edu
>>Subject: Re: [p2p-sip] Requirements Explosion
>>
>>
>>Henry Sinnreich wrote:
>>
>>    
>>
>>>>for basic audio-only no-NAT 
>>>>SIP user agent
>>>>   
>>>>
>>>>        
>>>>
>>>I hope we include presence and IM right from the start and 
>>>      
>>>
>>see no difference
>>    
>>
>>>if video will be there as well.
>>>
>>> 
>>>
>>>      
>>>
>>I believe, once we have a design to support audio-only SIP 
>>user agents 
>>following the external DHT approach (or DHT-based approach), 
>>it will be 
>>fairly straightforward to support presence, IM and video in 
>>that approach.
>>So I support Henry's proposal with respect to setting our 
>>very initial 
>>design target.
>>Thanks.
>>
>>Eunsoo
>>
>>    
>>
>>>Thanks, Henry 
>>>
>>>-----Original Message-----
>>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] 
>>>Sent: Wednesday, January 11, 2006 9:09 AM
>>>To: Kundan Singh
>>>Cc: p2p-sip at cs.columbia.edu
>>>Subject: Re: [p2p-sip] Requirements Explosion
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>So in conclusion, I think we should start with defining the generic 
>>>>location-service and P2P-service protocol, and then 
>>>>        
>>>>
>>specific data format 
>>    
>>
>>>>for SIP-location-service, and implement it for basic 
>>>>        
>>>>
>>audio-only no-NAT 
>>    
>>
>>>>SIP user agent and basic SIP proxy and registrar using some 
>>>>        
>>>>
>>existing 
>>    
>>
>>>>DHT/P2P algorithm.
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>I like this proposal a lot like many other people.
>>>Regards,
>>>
>>>Eunsoo
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>    
>>

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 11 Jan 2006 15:50:51 -0600

It looks Eunsoo has a very logical approach.

Thanks, Henry

-----Original Message-----
From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] 
Sent: Wednesday, January 11, 2006 2:53 PM
To: Drage, Keith (Keith)
Cc: henry at pulver.com; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Requirements Explosion

Regards,

Eunsoo

//
Drage, Keith (Keith) wrote:

>I'm afraid I have totally lost the purpose of this point-to-point SIP stuff
- or rather I think some of the other members of this list have.
>
>If it is going to be called SIP, then all entities must at least follow
some basic SIP compatibility rules. I assume also that SIP methods and
headers that normally operate between user agents will still operate between
user agents. It should only be protocol that is currently impacted by stuff
in the middle that should in any way be impacted by the scope of this work.
>
>So maybe can I propose that SIP p2p supports all SIP methods and headers
that normally operate only on a UA to UA basis. If we agree that, then we
automatically support 90% of all the SIP RFCs that exist out there,
including presence, IM and video. 
>Thus while I might expect that something like Path or Service-Route will
not work, or anything based on "trust domains", I would like to be confident
that something like SUBSCRIBE or Replaces does.
>
>If people really want to build something that doesn't do that, then surely
you need to change the title of the list, as it is no longer SIP - and we
will see where the IETF stand in terms of inventing a totally new VOIP
protocol.
>
>Remember, in Vancouver, I believe we were trying to address something that
could be done by an IETF group, the discussion I have seen over the last few
days seems to be determined to consign all the work to IRTF.

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 11 Jan 2006 16:54:48 -0500

One thing we mustn't forget is that it would be very kind if all these
different P2P applications could find,  verify and communicate with one
another.  Unless we want to balkanize things even further.

On 11/01/06, Henry Sinnreich <henry at pulver.com> wrote:
> >P2P SIP should only impact the protocol elements that deal with making
> sure
> that end-to-end stuff happens.
> >

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060111/8801e2a7/attachment.html