Subject: [p2p-sip] SIP, ICE, and an Overlay Network

From: RBrown at talkswitch.com (Rob Brown)
Date: Tue, 14 Mar 2006 16:43:46 -0500

Good summary.  The scope and goals are useful and achievable.

Regards,
Robert Brown

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Tuesday, March 14, 2006 4:20 PM
To: 'P2P-SIP'
Subject: [p2p-sip] SIP, ICE, and an Overlay Network

Ok, so if I understand this discussion:

1) The only problems we're trying to solve are decentralizing the SIP
proxy and STUN/TURN services.  Anything that doesn't relate to these
problems is out of scope.  (Specifically, the whole topic of NAT
traversal between UAs for media streams is entirely out of scope.)

2) While solving the problems in (1), we can make no significant change
to SIP itself.  In other words, our solution must seamlessly
interoperate with non-P2P SIP clients (for some definition of
'seamless').

3) We must craft our solution using the best of breeds techniques
available from the P2P community.  Thus we're focused on the
*engineering* problem, not the *research* problem.  (Specifically,
problems that haven't been clearly solved by the research community
won't be tackled by us, including many desirable security topics.)

Is this about right?

If so, I like the proposal of just focusing all our energy on creating a
top-notch overlay layer, and then documenting the "best practices" and
bindings in order to use this layer for SIP addressing, ICE resource
location, etc.  Thus we have a clean separation between our overlay
service, and the SIP service.

Unfortunately, because we're barred from modifying existing protocols
(beyond specific bindings, such as address types), that leaves us no
choice but to roll our own entirely new protocol from scratch.  Clearly
we can choose a model, or even standardize one that is already in use,
but it's still a bigger task than just piggypacking atop of SIP.  

But on the upside, it gives us a lot of flexibility, and simplifies the
problem space.  It nicely cleaves the work into:
- Creating an overlay service with a clean external interface
- Documenting how to use this overlay service by SIP and ICE

Does this sound about right?

-david

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