> the solution has to work on our current provided accounts : IP2IP / RING / SIP
What exactly do we mean when we say that it must work with SIP (and IP2IP)? Does that mean that it must potentially work with other SIP clients and various SIP servers... or only between two Ring clients connected via SIP? If its the latter case, then could we not limit ourselves to implementing it only for RING accounts (for now) since we wouldn't necessairly know if the recipient is connected using a Ring client in the case of SIP? -stepan ----- Original Message ----- From: "Guillaume Roguez" <[email protected]> To: [email protected] Sent: Wednesday, September 23, 2015 3:19:15 PM Subject: [Ring] file transfer proposal Hi, RingTeam wants to provide file transfer. And we want to do it fast! How fast? Saying in the order of a month. I've opened a Redmine ticket to track that: https://projects.savoirfairelinux.com/issues/80747 I'm going to report my design progress using this ML and I open the discussion. For my first report I see these facts: - - the solution needs to provide NAT-traversal => we already have a technology for that: ICE. But our implementation requires to use UDP transport - the solution has to provide handling API to request/start/stop file transfer - the solution has to provide meta-data display starting at request, to let recipient decides what to do (accept/refuse) - the solution has to provide authentification/encryption I've already identified some related protocols to help to solve this task (see ticket associated tasks): UDT over SIP/SDP, rfc5547/rfc4975, tftp, QUIC? As I want to keep the development in a relative short time and the an easy integration, I think that rfc5547/rfc4975 and QUIC are not the right solutions (too heavy to integrate). tftp is too simple and restritive for our needs. UDT is right for data transport but doesn't bring meta-data/session/authentification/encryption (need to be coupled to SIP/SDP and nettle/gnutls for authentification/encryption) This last is promising, re-using most of our already integrated technologies, but some refactoring remain if we want to keep transfer outside a call context (where the SIP/SDP session live). Any comments/ideas? -- Guillaume R. Ring Project Director _______________________________________________ Ring mailing list [email protected] https://lists.savoirfairelinux.net/mailman/listinfo/ring _______________________________________________ Ring mailing list [email protected] https://lists.savoirfairelinux.net/mailman/listinfo/ring
