Document the interplay of call_direction and resource_type (2600hz#6381)

doc/user_guides/call_recording.md

@@ -166,3 +166,35 @@ Key | Description | Type | Default | Required | Support Level
 `method` | What HTTP method to use when sending the recording | `string('put' | 'post')` | `put` | `false` |
 `time_limit` | Time limit, in seconds, for the recording | `integer()` | `3600` | `false` |
 `url` | The URL to use when sending the recording for storage | `string()` |   | `false` |
+
+### Interpreting call recordings and call direction
+
+Call direction is a field found in CDRs that indicates, from KAZOO's perspective, from whence the call was started. `inbound` indicates that the phone/carrier has sent the INVITE to Kazoo (inbound to KAZOO). `outbound` indicates that KAZOO is sending the INVITE to the phone/carrier (outbound from KAZOO).
+
+```
+inbound: PHONE ==INVITE==> KAZOO
+outbound: PHONE <==INVITE== KAZOO
+```
+
+Now a lot of calls will involve two phones:
+
+```
+PHONE_A ==INVITE==> KAZOO ==INVITE==> PHONE_B
+```
+
+The INVITE from `PHONE_A` is the `inbound` call leg while the INVITE from KAZOO to `PHONE_B` is the `outbound` leg.
+
+However, these directions are often not intuitive to end users. Most folks would say a call coming in from the PSTN is an `inbound` call while the call they place *to* the PSTN is an `outbound` call. UI clients, therefore, can't rely on just displaying the `call_direction` field of a call to indicate the direction of the call from the end user's perspective.
+
+When call recording is configured, the leg being recorded will include the recording information in its CDR. Additionally, if a leg is coming in from or going out to the PSTN, it will include a `resource_type` field in the CDR's `custom_channel_vars`. Fetching all legs involved (using the interaction_id), it should be possible to determine the direction of a call from the end user's perspective for the simple case:
+
+End User's Direction | Call Direction (A leg) | Resource Type (A leg) | Call Direction (B leg) | Resource Type (B leg) | Description
+-------------------- | ---------------------- | --------------------- | ---------------------- | --------------------- | -----------
+`inbound`            | inbound from PSTN      | `offnet-origination`  | outbound to the device | `undefined`           | A call in from the PSTN to a registered device
+`outbound`           | inbound from a device  | `undefined`           | outbound to the PSTN   | `offnet-termination`  | A call from a registered device to the PSTN
+
+Those are the simple cases, of course. Where it gets tricky is when a call comes in from the PSTN and is subsequently sent to a call-forwarded device (via PSTN). Both legs will have `resource_type` set. Or when a device calls another device, no `resource_type` will exist on either leg. Or when a call is transferred or parked/picked up (sometimes multiple times).
+
+The leg where call recording is started will have `media_recording_id` set (among others) in the leg's CDR under the `custom_channel_vars` object.
+
+Hopefully this section can serve as a jumping off point for UI clients to determine how to communicate to end users the direction of calls so that labeling recordings can be done in a way that makes sense for the end user.