Subject: [p2p-sip] Requirements Explosion

From: drage at lucent.com (Drage, Keith (Keith))
Date: Fri, 13 Jan 2006 15:19:04 -0000

Could I suggest then that part of the draft charter we write for the BOF contains something along the lines of:

(having of course scoped the mechanism first)

The mechanism will provide a means of sending a SIP method (possibly unknown) containing SIP headers (possibly unknown) and message bodies, to a SIP-URI or other URI within a Request-URI parameter.

This means we have a goal of supporting a large number of existing SIP mechanisms that already operate end to end, and which will continue to do so.

regards

Keith

> -----Original Message-----
> From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com]
> Sent: 11 January 2006 20:53
> To: Drage, Keith (Keith)
> Cc: henry at pulver.com; p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Requirements Explosion
> 
> 
> 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
> >>
> >>    
> >>
>