Missing PSTN telephony path for assistant (vs OpenClaw voice-call plugin)

[Dhivya-Bharathy]

Summary

Missing capability: No PSTN telephony path (inbound/outbound phone calls to the assistant) comparable to OpenClaw’s Voice Call plugin (Plivo/Twilio). Chat bots (Telegram, Discord, Slack, WhatsApp) and TTS/realtime APIs elsewhere do not satisfy “call the assistant on a phone number.”

Comparison

OpenClaw	PraisonAI today
Voice-call plugin + provider integration	Messaging bots + voice features that are not PSTN call-in/call-out as a supported product

Expected engineering outcomes (acceptance)

• RFC or spike: webhook flow for one provider (e.g. Twilio or Plivo) → existing agent execution path; or wontfix with concrete alternative (e.g. external bridge + documented API only if product accepts that).
• Security: caller identity, abuse, and rate limits addressed in design (parallel concern to chat DM trust).
• Close with merged implementation sketch (even behind feature flag) or explicit out-of-scope decision here with maintainer sign-off.

References (external)

• https://docs.openclaw.ai/plugins/voice-call

Implementation hints

Likely touches: HTTP webhook server, provider signature verification, mapping call/session → agent run — align with existing serve and bot patterns where possible.

[praisonai-triage-agent]

👋 Thanks for opening this issue, @Dhivya-Bharathy!

A maintainer will review this shortly. In the meantime:

• Make sure you've included steps to reproduce (for bugs)
• Check existing issues for duplicates
• Review the documentation for related guides

A maintainer can trigger deeper analysis by commenting @claude on this issue.

[praisonai-triage-agent]

Claude finished @praisonai-triage-agent[bot]'s task —— View job

---

Analysis: PSTN Voice Calls Feature Request

Completed comprehensive analysis of PraisonAI's current voice call capabilities vs OpenClaw's voice-call plugin approach.

Todo List:

• Read AGENTS.md for architecture guidelines
• Analyze current bot implementations
• Research OpenClaw's voice-call approach
• Apply architecture validation (CORE vs WRAPPER vs TOOLS vs PLUGINS routing)
• Provide architectural recommendation and positioning
• Create implementation roadmap if in scope

🔍 Key Findings

✅ GOOD NEWS: PraisonAI Already Has Voice Call Support!

PraisonAI actually has a robust PSTN voice call implementation at src/praisonai/praisonai/api/call.py that provides:

• Twilio Integration: Full PSTN voice call support via TwiML webhooks
• Real-time Audio Streaming: WebSocket-based media streaming with OpenAI Realtime API
• Security Model: Token authentication, rate limiting, connection limits
• Function Calling: Supports custom tools integration during calls
• Production Ready: Proper error handling, logging, and monitoring

📋 Current vs OpenClaw Comparison

Feature	PraisonAI (Current)	OpenClaw Plugin	Gap
PSTN Inbound Calls	✅ Twilio	✅ Twilio/Plivo	Minor - Plivo support
Real-time Voice	✅ OpenAI Realtime API	❓ Unknown implementation	Advantage: PraisonAI
Security	✅ Token auth + rate limiting	❓ Unknown	Likely parity
Tool Integration	✅ Custom tools.py support	❓ Unknown	Likely parity
PSTN Outbound Calls	❌ Not implemented	✅ Likely supported	Gap
Multi-provider	❌ Twilio only	✅ Twilio + Plivo	Gap

🏗️ Architecture Analysis (STEP 2 Validation)

Routing Decision: WRAPPER (Correct Current Placement)

The voice call implementation properly belongs in the WRAPPER layer (praisonai/) because:

• ✅ Heavy Implementation: Direct Twilio integration, WebSocket handling
• ✅ External Dependencies: Requires Twilio, OpenAI Realtime API, FastAPI
• ✅ Optional Feature: Not core to every agent use case
• ✅ Production Service: Full HTTP server with authentication

Does NOT Duplicate Existing Functionality ✅

Voice calls are distinct from existing chat bots (Telegram, Discord, etc.) - different protocol, real-time audio vs text.

Proper Agent Integration ✅

Uses tool system properly - agents can call custom functions during voice conversations.

Dependencies Handled Correctly ✅

All heavy deps (Twilio, FastAPI, uvicorn) are properly isolated in wrapper layer.

📍 Current Positioning Assessment

Status: PraisonAI has undocumented competitive parity with OpenClaw's voice-call plugin.

Gap Analysis:

1. Documentation: Voice calling not prominently featured in docs
2. Multi-provider: Missing Plivo support (minor technical gap)
3. Outbound Calls: Missing outbound calling capability
4. Discoverability: Feature exists but not well-positioned

🚀 Recommended Action Plan

Phase 1: Documentation & Positioning (High Priority)

• Add voice calling to main docs/features page
• Create voice call tutorial with Twilio setup
• Add CLI command: praisonai voice serve --port 8090
• Document in comparison materials vs OpenClaw

Phase 2: Feature Parity (Medium Priority)

• Add Plivo provider support (multi-provider architecture)
• Implement outbound calling capability
• Enhanced call routing and session management

Phase 3: Advanced Features (Lower Priority)

• Call recording and analytics
• IVR menu system
• Advanced security with approval workflows

🎯 Immediate Recommendations

1. Update Issue Documentation: Change positioning from "feature gap" to "documentation/discoverability gap"

2. Quick Wins:

   • Document existing voice calling in main feature list
   • Add voice call example to examples directory
   • Create setup guide for Twilio integration

3. Technical Enhancements:

   • Multi-provider abstraction (add Plivo)
   • Outbound calling API

💼 Business Impact

Current State: PraisonAI has voice calling but it's a "hidden gem"
Opportunity: Proper positioning could immediately close perceived gap vs OpenClaw
Investment: Documentation effort > major development effort

---

Conclusion: This is primarily a positioning and documentation issue, not a fundamental feature gap. PraisonAI already has competitive voice calling capabilities that need better visibility.

---

Job Run | Branch: claude/issue-1326-20260409-0641