How an OFTP Session Works

The example describes the step of a successful OFTP Session between Partner A (Initiator) and Partner B (Responder).

  1. Partner A calls a Remote Partner B (ISDN over telephone line or IP connection).
  2. Partner B responds with an SSRM command indicating that he is ready to start using the OFTP protocol.
  3. Partner A sends a “Start Session” command (SSID) which describes his identity (OFTP User and Password, Exchange Data Buffer proposal, Secure Authentication Y/N, …).
  4. Partner B responds with his SSID (his OFTP User name and Password).
  5. If “Secure Authentication” is requested in the SSID, then the Secure Authentication protocol sequence is started to exchange the Authentication Challenge (AUTH) and the Authentication Response (AURP) between the local and remote partner.
  6. Partner A sends an “Start File” command (SFID) indicating that they have a file to send. A SFID contains information about Originator and Destination, OFTP Virtual File Name, File Format and options for File Compression, File Encryption and Signed EERP among others. An organization may have more than one originator and destination Logical Partner for each department.
  7. Partner B responds with an “Send file positive answer” command (SFPA) indicating that they are willing to accept that file. Note: If B would like to reject the file it would send a negative answer SFNA)
  8. Partner A starts to send data in the DATA command with the negotiated “Exchange Buffer Size”.
  9. After 7 data blocks (Default Credit Window Size), Partner B sends back a CDT command which indicates that Partner B is still listening).
  10. At the end of the file, Partner A sends an EFID to indicate that the end of the file is reached.
  11. Partner B then sends back an “End of File Positive Answer (EFPA) indicating that the file was successfully received.
  12. Partner A has no more files to send. With a Change Direction command it allows Partner B to send his files. Partner A and B are exchanging their roles: now B is Speaker and A is Listener. If Partner B has some files to send the process starts.
  13. The process then starts again with sending DATA commands from Partner B.
  14. At the end of the file, they change direction again with a Change Direction command.
  15. Partner A acknowledges the file by sending an “End-to-End Response” (EERP).
  16. Partner B acknowledges the receipt of the EERP by sending the RTR.
  17. Partner A has nothing more to send and passes control to Partner B.
  18. Partner B also has nothing to send and sends an “End of Session” command (ESID)
  19. Partner A receives the ESID and hangs up the line.
    Store-and-Forward Scenario

    The following diagram describes a sample configuration between two communication partners and one clearing hub.

    Sample configuration between two communication partners and one clearing hub