Re: [P2PSIP] Trying to grasp what we really are standardizing...

Hi, 

If P2PSIP overlay is intended to convey SIP(3261,3263) messages, there would be some contradictions.
SIP(3261,3263) in nature is based on client/server architecture. But P2P overlay is different.

So, P2PSIP overlay will transfer session setup (initiation) messages on peer to peer overlay 
while it can be proxy of SIP (3261 and 3263) just for compatibility.
I  do not agree to make SIP over P2P as a main purpose. 

P2PSIP should have its own architecture to have session setup function and to process NAT  traversal or firewall. 

Regards,

Gengyu

----- Original Message ----- 
From: "Greger V. Teigre" <greger@teigre.com>
To: "P2PSIP Mailing List" <p2psip@ietf.org>
Sent: Monday, June 25, 2007 6:00 PM
Subject: [P2PSIP] Trying to grasp what we really are standardizing...

> It seems to me (based on the drafts) that this working group has set out 
> to standardize too much. However, I may be unable to see the big picture 
> after reading the drafts...
> 
> I'm trying to use a (simplistic) layered approach, please help me sort 
> out my confusions...
> 
> The logical starting point for me is the pure SIP UA (already out 
> there). It will (hopefully) support sip-outbound and ice.  It will thus 
> expect to find a registrar, as well as a STUN and a STUN relay function. 
> Using these mechanisms, the UA will happily REGISTER with the assigned 
> registrar, establish the necessary sip-outbound flows and will negotiate 
> using ice when setting up a dialog. 
> 
> For simplicity, let's say the registrar happens to be a P2PSIP peer 
> physically residing on another device. This peer should have a SIP 
> implementation, as well as a p2p implementation. This peer should be 
> able to act as a registrar for the SIP UA, including ping-pongs, do 
> routing, and offer STUN relay addresses when an INVITE goes through 
> (contrary example, draft-marocco-p2psip-interwork-01 seems to indicate 
> some p2psip-aware code in the SIP UA).  In my mind, the P2P layer should 
> offer the SIP-part of the peer an API where messages can be routed and 
> relay function data retrieved, (draft-baset-p2psip-p2pcommon-01 seems to 
> be closest, but concerns a protocol on the wire) however, implementing 
> the API in the SIP code should be a fairly simple one-to-one mapping.
> 
> The API should be standardized in this working group, so that any SIP 
> implementor having implemented the P2PSIP API can plug in a new p2p 
> implementation (or support several). These implementations could be 
> different overlays or different libraries implementing the same 
> overlays. Hopefully, all the various available p2p implementations will 
> implement this API, thus ensuring that SIP UA implementations quickly 
> will become p2p aware.
> 
> So far so good, NAT has been handled on the SIP layer for both signaling 
> and media, and the only thing we need is an implementation of the P2PSIP 
> API that realizes the API functions...
> 
> However, now I start to get a bit confused. We want to standardize to 
> ensure interoperability. Well, with a well-designed P2PSIP API, we have 
> come pretty far, I think. We have interoperability using all the SIP 
> mechanisms, including 3263. SIP messages can flow across overlays on the 
> SIP layer. So, what more do we want to ensure? That various 
> implementations on the p2p layer can talk to each other? Why do we want 
> that?  Won't we just freeze innovation because we are not able to create 
> a protocol between the peers that is agnostic to hash tables etc? I know 
> the charter says we should standardize the protocol between the peers, 
> but I feel that SIP and p2p is mixed together too much and I just don't 
> get it.
> 
> Ok, so people want interoperability between p2p peers, but I don't 
> really see how we can avoid spending a lot of resources on just creating 
> a default that probably quickly will be outdated?! (we're not 
> standardizing a best practice that has emerged already)  And I don't 
> really see what we gain (unless the ambition is to create a world-wide 
> p2p network where also non-SIP can be transported...).
> 
> So, based on my lack of understanding of the above, pardon my lack of 
> understanding on some other issues:
> - How NAT is handled on the p2p layer should have nothing to do with the 
> SIP layer.  One should be free to make any decision, right?
> - Whether to use SIP, binary, or some text-based protocol (if to be 
> standardized) should really be based on facts: what works most 
> efficiently from a *protocol standpoint*? Let's not get confused by the 
> fact that SIP will be transported on top of the p2p protocol.
> - Choosing of transport-layer protocols: again, ignore SIP, what works?
> 
> Of course, as both the SIP and p2p layers must solve NAT traversal, it 
> is easy to mix them together and yes, I'm open to the possibility of 
> collapsing the layers for optimization reasons. But I don't think we are 
> there yet. And I also think that through some separation, the p2p guys 
> (I'm not one of them) and the SIP guys can concentrate on what they are 
> good at. If we mix, only people who are experts on both can a) implement 
> b) have an opinion.
> 
> Please,attack my arguments.
> g-)
> 
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>