vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-05-06 15:50:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: log meet twilio voice flow

Browse Source
This commit is contained in:
Peter Steinberger
2026-05-01 07:38:31 +01:00
parent fc1c597dbf
commit c677861032
10 changed files with 65 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/plugins/google-meet.md
View File

@@ -1133,6 +1133,8 @@ Expected Twilio state:
`twilio-voice-call-credentials`, and `twilio-voice-call-webhook` checks.
- `voicecall` is available in the CLI after Gateway reload.
- The returned session has `transport: "twilio"` and a `twilio.voiceCallId`.
- `openclaw logs --follow` shows DTMF TwiML served before realtime TwiML, then a
realtime bridge with the initial greeting queued.
- `googlemeet leave <sessionId>` hangs up the delegated voice call.
## Troubleshooting
@@ -1407,6 +1409,10 @@ participant:
active.
- Run `openclaw voicecall tail` and check that Twilio webhooks are arriving at
the Gateway.
- Run `openclaw logs --follow` and look for the Twilio Meet sequence: Google
Meet delegates the join, Voice Call stores pre-connect DTMF TwiML, serves
that initial TwiML, then serves realtime TwiML and starts the realtime bridge
with `initialGreeting=queued`.
- Re-run `openclaw googlemeet setup --transport twilio`; a green setup check is
required but does not prove the meeting PIN sequence is correct.
- Confirm the dial-in number belongs to the same Meet invitation and region as
@@ -1414,9 +1420,9 @@ participant:
- Increase the leading pauses in `--dtmf-sequence` if Meet answers slowly, for
example `wwww123456#`.
- If the participant joins but you do not hear the greeting, check
`openclaw voicecall tail` for a Twilio stream start followed by realtime
provider readiness. The greeting is now generated from the initial
`voicecall.start` message after the stream connects.
`openclaw logs --follow` for realtime TwiML, realtime bridge startup, and
`initialGreeting=queued`. The greeting is generated from the initial
`voicecall.start` message after the realtime bridge connects.
If webhooks do not arrive, debug the Voice Call plugin first: the provider must
reach `plugins.entries.voice-call.config.publicUrl` or the configured tunnel.

18
docs/plugins/voice-call.md
View File

@@ -723,6 +723,7 @@ Then inspect runtime state:
```bash
openclaw voicecall status --call-id <id>
openclaw voicecall tail
openclaw logs --follow
```
Common causes:
@@ -775,6 +776,19 @@ For Twilio calls, Voice Call serves the DTMF TwiML first, redirects back to the
webhook, then opens the realtime media stream so the saved intro is generated
after the phone participant has joined the meeting.
Use `openclaw logs --follow` for the live phase trace. A healthy Twilio Meet
join logs this order:
- Google Meet delegates the Twilio join to Voice Call.
- Voice Call stores pre-connect DTMF TwiML.
- Twilio initial TwiML is consumed and served before realtime handling.
- Voice Call serves realtime TwiML for the Twilio call.
- The realtime bridge starts with the initial greeting queued.
`openclaw voicecall tail` still shows persisted call records; it is useful for
call state and transcripts, but not every webhook/realtime transition appears
there.
### Realtime call has no speech
Confirm only one audio mode is enabled. `realtime.enabled` and
@@ -785,8 +799,8 @@ For realtime Twilio calls, also verify:
- A realtime provider plugin is loaded and registered.
- `realtime.provider` is unset or names a registered provider.
- The provider API key is available to the Gateway process.
- `openclaw voicecall tail` shows the media stream accepted and realtime
provider readiness before the initial greeting.
- `openclaw logs --follow` shows realtime TwiML served, the realtime bridge
started, and the initial greeting queued.
## Related