Skip to content

VAP-999: fix: restore issues on DTMF docs #314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 18, 2025
Merged

VAP-999: fix: restore issues on DTMF docs #314

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 1 addition & 11 deletions fern/tools/default-tools.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,18 +113,8 @@ This function is provided when `dtmf` is included in the assistant's list of ava
}
```

<Note>
There are three methods for sending DTMF in a phone call:

1. **In-band DTMF**: DTMF tones are transmitted as part of the regular audio stream. This is the simplest method, but it can suffer from quality issues if the audio stream is compressed or degraded.
2. **Out-of-band DTMF via RFC 2833**: This method sends DTMF tones separately from the audio stream, within RTP (Real-Time Protocol) packets. It's typically more reliable than in-band DTMF, particularly for VoIP applications where the audio stream might be compressed. RFC 2833 is the standard that initially defined this method. It is now replaced by RFC 4733 but this method is still referred by RFC 2833.
3. **Out-of-band DTMF via SIP INFO messages**: In this approach, DTMF tones are sent as separate SIP INFO messages. While this can be more reliable than in-band DTMF, it's not as widely supported as the RFC 2833 method.

As of writing, Vapi's DTMF tool uses in-band DTMF. Please note that this method may not work with certain IVRs. If you are running into this issue, the recommended approach is to have your assistant say the options out loud if available. For example, when an IVR says "Press 1 or say Sales for the Sales department," prefer having the assistant say "Sales."
</Note>

#### Send Text

1. **In-band**: tones are transmitted as part of the regular audio stream. This is the simplest method, but it can suffer from quality issues if the audio stream is compressed or degraded.
2. **Out-of-band via RFC 2833**: tones are transmitted separately from the audio stream, within RTP (Real-Time Protocol) packets. It's typically more reliable than in-band DTMF, particularly for VoIP applications where the audio stream might be compressed. RFC 2833 is the standard that initially defined this method. It is now replaced by RFC 4733 but this method is still referred by RFC 2833.
3. **Out-of-band via SIP INFO messages**: tones are sent as separate SIP INFO messages. While this can be more reliable than in-band DTMF, it's not as widely supported as the RFC 2833 method.
Expand Down Expand Up @@ -200,4 +190,4 @@ At the assistant level, the `serverUrl` can be specified in the assistant config
If the `serverUrl` is not defined either at the account level or the assistant level, the function call will simply be added to the chat history. This can be particularly useful when you want a function call to trigger an action on the frontend.

For instance, the frontend can listen for specific function calls in the chat history and respond by updating the user interface or performing other actions. This allows for a dynamic and interactive user experience, where the frontend can react to changes in the conversation in real time.
</Accordion>
</Accordion>
Loading