diff --git a/tutorials/File-transfer.md b/tutorials/File-transfer.md
index 909e2326..46d36825 100644
--- a/tutorials/File-transfer.md
+++ b/tutorials/File-transfer.md
@@ -63,7 +63,23 @@ The first part will be a small header to describe the content of the file. Then,
 
 ##### Receiving a file
 
-**TODO**
+The following method is used:
+
+1\. A client will call `DataTransferFacade::sendFile()`. `DataTransferFacade` is the class corresponding to the API exposed for the clients. It is used to manage a view of the file transfers (the corresponding classes are `DataTransfer`, `IncomingFileTransfer`, `OutgoingFileTransfer` and `SubOutgoingFileTransfer`). This method will ask the linked `JamiAccount` to request a connection.
+
+**TODO schema**
+
+2\. The method `DhtPeerConnector: requestConnection()` is triggered and creates a connection between all connected devices of the peer (found on the DHT). `DhtPeerConnector` is used to manage the main event loop which manage connections. When a device is found, the *event loop* will create a `ClientConnector` (which manage the connection for one device) and launch the `process()` method.
+
+3\. This method is used to initialize the ICE transport and put a *PeerConnectionMsg* (which contains the SDP message, see below) on the DHT and waits for a response (`DhtPeerConnector::Impl::onResponseMsg`).
+
+4\. Then a response is received from the DHT, which contains public addresses of the peer device. We can now negotiate a TLS link (directly via ICE, or via TURN as a fallback). This `TlsSocketEndpoint` is given to the `PeerConnection` object as an output and the transfer can start.
+
+5.\ When the TLS socket is ready, the callback `DataTransferFacade::Impl::onConnectionRequestReply` is called, and a `OutgoingFileTransfer` is linked to the `PeerConnection` as an input. This `OutgoingFileTransfer` contains a list of `SubOutgoingFileTransfer` (one per device) where each sub transfer is a transfer to one device. We do that to be able to furnish the most optimistic view of the transfer (if a contact as 3 devices, where the contact cancel the transfer on one device, but accepted the transfer on the two others, the most advanced transfer will be shown).
+
+6\. The `SubOutgoingFileTransfer` will first transfer the header of the file, wait the peer acceptance (A "GO\n" message on the socket) and then will send the file.
+
+7\. If a cancel is received from the peer or the client or if the file transfer finish, the connection will be closed via a `CANCEL` message on the `DhtPeerConnector::eventLoop()` and the resources will be released.
 
 ##### Schema
 
@@ -108,34 +124,6 @@ Note that the stack for the file transfer is:
 ```
 
 
-#### Sending files
-
-The following method is used:
-
-1\. A client will call **DataTransferFacade::sendFile()**
-
-2\. The method **DhtPeerConnector: requestConnection()** is triggered and
-creates a connection between all connected devices of the peer. This
-will create a **ClientConnector** and launch the **process()** method.
-
-3\. This method put a *PeerConnectionMsg* on the DHT and waits for a
-response (**DhtPeerConnector::Impl::onResponseMsg**). The reponse will
-contains informations to connect to the peer.
-
-4\. Then a response is received from the DHT, which contains public
-address of the contact. A **TcpSocketEndpoint** is created and wrapped
-in a **TlsSocketEndpoint** wrapped in a **PeerConnection** object (and
-launch **PeerConnection::PeerConnectionImpl::eventLoop()**)
-
-5\. This connection is given to
-**DataTransferFacade::Impl::onConnectionRequestReply** and attached to a
-**OutgoingFileTransfer**
-
-6\. **PeerConnection::PeerConnectionImpl::eventLoop()** as soon as the
-output is connected will send headers (from **SubOutgoingFileTransfer**)
-to the peer. And will wait for the "GO" message (or "NGO"). Then if
-headers are sent and the file accepted, it will send the rest of the
-file until the connection is closed or the file is finished.
 
 #### Receiving files