Hi Julian,
thanks for your detailed answer. At least one of it sound familiar :) I
know Benny and his fin pjsip stack. We've already implemented AKA Digest
Authentication together in the past...
However, the project I'm involved in, is more ore less a demonstrator.
It doesn't have productive aims up to now, so we are allowed to call it
RELOAD but let significant parts of RELOAD aside. For instance the
parts, I've outlined in my initial post. In my limited overview I always
treated RELOAD as "just the standardized transport for a DHT". I think I
would be happy to have at least the basic RELOAD transport w/o
STUN/TURN/ICE/NAT, probably also without TLS, because all of the nodes,
participating in the overlay, are in trusted environments...
Having this in mind, wouldn't it be better to implement the basic RELOAD
transport PDUs and means first, and let all the security and
configuration overhead aside?
jc schrieb:
Neil,
Start with enrollment and then move on to security and then ICE. The
reasoning here is that you MUST have a configuration file to setup
security and you need the security implementation to implement ICE
Attach. This is because of where the a Node ID is stored. You will
need to implement DNS SRV in order to implement enrollment. I used
c-ares for testing and then implemented DNS SRV myself. I use C++ but
surely there is DNS SRV support built into .NET?
If your looking for an easy to use and highly scalable STUN/TURN
server that is up to date have a look at using reTurn in the
resiprocate svn repository. There is also Numb STUN/TURN server
however it has been obsoleted by rfc5389 and doesn't look to be worked
on anymore. As a 2nd option there is the pjnath library as part of the
pjsip project. You could code a C# wrapper for pjnath and use that on
your client side for the ICE transports, of course you will have to
implement TLS and DTLS over these yourself as TLS in pjnath is used as
it should be in the context of TURN.
Having said that I implemented STUN/TURN and ICE myself to remove
these dependancies but did start off using pjnath(GPL) on the client
for ICE and reTurn on the server side. Now I shared a common code base
between p2p code and managed server code which makes things much
easier to maintain.
Julian
On Oct 16, 2009, at 9:14 AM, neil.young wrote:
Hi,
I recently finished the development of a CHORD implementation in C#.
I already use a proprietary binary TCP communication protocol for the
CHORD messages (findsuccessor, the notify and stabilize routines, the
ping etc.). In near future I want to proceed to RELOAD, whereas the
desired implementation does not necessarily has to have full RELOAD
characteristics as the first result. Especially these items are not
required initially, so that the first implementation would more be a
REL instead of RELOAD :)
1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server
Implementors, could you give me please some suggestions, where to
start with best under these circumstances?
Kind regards
_______________________________________________
P2PSIP mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
