In any R/3 System, CALL FUNCTION is an integral part of the ABAP language (in R/2 from Release 5.0 onwards). It is used to perform a function (function module) in the same system (R/2 or R/3).
REMOTE FUNCTION CALL (RFC) is an extension of CALL FUNCTION in a distributed environment. Existing function modules can be executed from within a remote system (R/2 or R/3) via an RFC call. This is done by adding a DESTINATION clause to the CALL FUNCTION statement:

The destination parameter displays an entry in the RFCDES table (which is defined with transaction sm59). This entry contains all necessary parameters to connect to and log in the destination system.
RFC can be used between SAP Systems (R/3 and R/2 Systems). With R/2 in an IBM environment, RFC is currently possible only with CICS as a DC system from Release 5.0D onwards. In IMS environment, RFC will probably not be available before IMS >= 4.1 and complete support of the LU6.2 protocol (via MVS/APPC).
The RFC API on OS/2, Windows, Windows NT and all R/3-based UNIX platforms makes it possible to use the RFC functionality between an SAP System (R/3 from Release 2.1 and R/2 from Release 5.0D onwards) and a C program on the above platforms. It is of no significance to the caller whether the remote function is provided in an SAP System or in a C program.
RFC frees the ABAP programmer from having to program his own communications routines. When you make an RFC call, the RFC interface takes care of:

There is no support for Dictionary structures.
The RFC interface is effectively invisible to the ABAP programmer. Processing for calling remote programs is built into the CALL FUNCTION statement. Processing for being called is generated automatically (in the form of an RFC stub) for every function module registered as remote. This stub serves as an interface between the calling program and the function module.
A distinction is made between an RFC client and RFC server. RFC client is the instance that calls up the Remote Function Call to execute the function that is provided by an RFC server. In the following, the functions that can be executed remotely will be called RFC functions and the functions provided via RFC API will be called RFC calls.
All RFC functions available in a remote RFC server system, which are called by an RFC client, are processed transactionally. This means that after execution of the first RFC function in the RFC server system the complete context (all globally defined variables in the RFC server program or in the main program of a function module) is available for further RFC functions. The RFC connection is closed only
Until Release 3.0 the connection to an R/3 System must be established to a previously defined application server. From Release 3.0 onwards, it is also possible to have an application server assigned by the message server on the basis of a load balancing procedure. This applies both for RFC between R/3 systems and between external systems and R/3 systems.
To make the execution of RFC functions reliable, safe and independent from the availability of the RFC server or RFC server system, the transactional RFC (tRFC) was introduced for R/3 systems from Release 3.0 onwards. This ensures that the called function module is executed only once in the RFC server system.
In transactional RFC calls, the data that belongs to an RFC function must first be stored temporarily on the SAP database in the RFC client system. When processing is completed, this must be reported back to the calling ABAP program. Everything else is handled by the tRFC component in the R/3 System.
Since a database is not always available on external systems, the link to the tRFC interfaces is implemented such that the client or server programs based on RFC API must take on some administrative functions to ensure that the respective function module is executed "only once".

In an R/3 System, other R/3 Systems can be defined as trusted systems. Trusted systems can access the called system (the trusting system) without having to provide a password.
For more information, see