⚠️ IMPORTANT: This is a Functional Example, Not Production-ReadyThis project is designed as a functional example for customers and developers building on BYOVA (Bring Your Own Virtual Agent). It demonstrates best practices for coding and well-documented methods for interfacing with BYOVA, but it is NOT intended to be a fully production-ready application.
Purpose: This gateway serves as a reference implementation that customers can:
- Fork and build upon for their own implementations
- Extract specific parts and pieces they need to understand BYOVA integration
- Learn best practices for connecting to different voice agent services
- Use as a starting point for their own BYOVA integrations
This document provides guidance for AI agents working with this codebase. It explains the architecture, design patterns, and conventions used in the Webex Contact Center BYOVA (Bring Your Own Virtual Agent) Gateway.
The Webex Contact Center BYOVA Gateway is a Python-based gateway that acts as a bridge between Webex Contact Center (WxCC) and various virtual agent providers. It enables seamless voice interactions by implementing the required gRPC interfaces and routing requests to appropriate vendor-specific connector implementations.
The primary purpose of this gateway is to:
- Serve as a functional example for customers implementing BYOVA integrations
- Demonstrate best practices for coding and documentation
- Provide a flexible integration layer between WxCC and virtual agent platforms
- Abstract vendor-specific implementations behind a common interface
- Enable easy addition of new virtual agent connectors through well-defined patterns
- Provide monitoring and debugging capabilities for development and testing
- Show customers how to interface with BYOVA through practical, working code
This gateway is specifically designed for:
- Developers who need to understand BYOVA integration patterns
- Customers who want to build their own voice agent integrations
- Architects who need to understand the design patterns for BYOVA
- DevOps teams who want to see examples of monitoring and deployment patterns
The gateway follows a modular architecture with the following key components:
┌───────────────┐
│ WxCC gRPC │
│ Interface │
└───────┬───────┘
│
┌───────▼───────┐
│ Gateway │
│ Server │
└───────┬───────┘
│
┌───────▼───────┐
│ Virtual Agent │
│ Router │
└───────┬───────┘
│
┌────────────────┬──────┴───────┬─────────────────┐
│ │ │ │
┌──────────▼─────────┐ ┌─▼────────┐ ┌─▼──────────┐ ┌─▼────────────────┐
│ Local Audio │ │ Vendor A │ │ Vendor B │ │ Custom Connector │
│ Connector │ │Connector │ │Connector │ │ (Your impl) │
└──────────┬──────────┘ └──────────┘ └────────────┘ └──────────────────┘
│
┌──────▼──────┐
│ Audio Files │
└─────────────┘
webex-byova-gateway-python/
├── audio/ # Audio files for local connector
├── config/
│ └── config.yaml # Main configuration file
├── proto/ # Protocol Buffer definitions
├── src/
│ ├── connectors/ # Virtual agent connector implementations
│ │ ├── i_vendor_connector.py
│ │ └── local_audio_connector.py
│ ├── core/ # Core gateway components
│ │ ├── virtual_agent_router.py
│ │ ├── wxcc_gateway_server.py
│ │ └── *.py # Generated gRPC stubs
│ └── monitoring/ # Web monitoring interface
│ ├── app.py
│ └── templates/
├── main.py # Main entry point
├── requirements.txt # Python dependencies
└── README.md
- Implements the
VoiceVirtualAgentServicergRPC interface - Manages conversation state through
ConversationProcessorinstances - Handles bidirectional streaming for voice interactions
- Routes requests to the appropriate virtual agent via
VirtualAgentRouter - Tracks connections and manages session lifecycle
Core Methods:
ListVirtualAgents: Returns available virtual agentsProcessCallerInput: Bidirectional streaming for voice interactions
- Loads and manages vendor connector instances
- Maintains agent-to-connector mappings
- Routes requests to the appropriate connector based on agent ID
- Provides connector and agent information for monitoring
Core Methods:
load_connectors: Dynamically loads connector implementations from configurationroute_request: Routes requests to the appropriate connectorget_connector_for_agent: Retrieves the connector instance for a specific agent ID
- Abstract base class defining the interface for vendor connectors
- All connector implementations must inherit from this class
- Provides a unified interface for vendor-specific implementations
Required Implementations:
start_conversation: Initializes a new conversation with the virtual agentsend_message: Sends audio or event data to the virtual agentend_conversation: Terminates a conversationget_available_agents: Returns a list of available agent IDsconvert_wxcc_to_vendor: Converts from WxCC format to vendor formatconvert_vendor_to_wxcc: Converts from vendor format to WxCC format
- Manages state for an individual conversation
- Processes different input types (audio, DTMF, events)
- Converts between gRPC and connector formats
- Handles error conditions and conversation cleanup
This gateway is designed to be educational and instructive for customers implementing BYOVA integrations. When working with this codebase:
- Study the patterns: Each connector demonstrates how to properly implement the BYOVA interface
- Learn from examples: The existing connectors show real-world integration approaches
- Use as templates: Copy and modify connector patterns for your own implementations
- Understand best practices: The code follows enterprise-grade coding standards and patterns
- Reference the architecture: Use the modular design as a blueprint for your own systems
To add support for a new virtual agent platform (or to learn how to create your own):
- Create a new connector class in
src/connectors/ - Inherit from
IVendorConnectorand implement all required methods - Implement vendor-specific logic in the connector class
- Add configuration in
config/config.yaml - Test with the monitoring interface
Example Connector Structure:
from src.connectors.i_vendor_connector import IVendorConnector
class MyNewConnector(IVendorConnector):
def __init__(self, config):
self.api_key = config.get("api_key")
self.endpoint = config.get("endpoint")
# Initialize vendor-specific client/SDK
def start_conversation(self, conversation_id, request_data):
# Implement vendor-specific conversation start logic
pass
def send_message(self, conversation_id, message_data):
# Implement vendor-specific message handling
pass
def end_conversation(self, conversation_id, message_data=None):
# Implement vendor-specific conversation end logic
pass
def get_available_agents(self):
return ["My Vendor Agent 1", "My Vendor Agent 2"]
def convert_wxcc_to_vendor(self, grpc_data):
# Convert WxCC format to vendor format
pass
def convert_vendor_to_wxcc(self, vendor_data):
# Convert vendor format to WxCC format
passThe gateway is configured via config/config.yaml. Configuration should follow this structure:
# Gateway settings
gateway:
host: "0.0.0.0"
port: 50051
# Monitoring interface
monitoring:
enabled: true
host: "0.0.0.0"
port: 8080
# Connectors
connectors:
- name: "connector_id"
type: "connector_type"
class: "ConnectorClassName"
module: "connectors.module_name"
config:
# Connector-specific configuration
api_key: "your_api_key"
endpoint: "https://api.vendor.com"The gateway implements the VoiceVirtualAgentServicer interface with these methods:
-
ListVirtualAgents: Returns available virtual agents- Input:
ListVirtualAgentsRequest - Output:
ListVirtualAgentsResponsewith agent IDs and metadata
- Input:
-
ProcessCallerInput: Bidirectional streaming for voice interactions- Input: Stream of
VoiceVARequestmessages - Output: Stream of
VoiceVAResponsemessages
- Input: Stream of
The web monitoring interface provides these endpoints:
GET /: Main dashboardGET /api/status: Gateway statusGET /api/connections: Connection dataGET /health: Health checkGET /api/debug/sessions: Debug information
The gateway can be tested using:
-
Direct gRPC Client Testing
- Use a gRPC client to call the gateway API directly
- Generate test audio files for the local connector
- Mock vendor responses for integration testing
-
Web Interface Testing
- Use the monitoring interface to view connection status
- Create test sessions via the debug API
- Monitor real-time gateway metrics
-
Load Testing
- Test with multiple simultaneous connections
- Verify thread safety and resource management
- Monitor memory usage under load
When submitting PRs to this project:
-
Naming
- Use descriptive PR titles with prefix (e.g., "fix:", "feat:", "docs:")
- Reference issue numbers if applicable
-
Contents
- Include clear description of changes and rationale
- Link to any related issues or documentation
- List any breaking changes or dependencies
-
Code Quality
- Ensure code follows project style guidelines
- Include appropriate error handling and logging
- Add tests for new functionality
-
Documentation
- Update documentation for new features or changes
- Add docstrings for new classes and methods
- Update configuration examples if needed
- Follow PEP 8 style guide
- Use type annotations for function parameters and return values
- Document classes and methods with docstrings
- Use meaningful variable and function names
- Keep functions focused and concise
- Use the built-in logging module
- Include appropriate log levels (DEBUG, INFO, WARNING, ERROR)
- Add context to log messages (e.g., conversation ID)
- Avoid excessive logging in normal operation
- Use specific exception types
- Provide meaningful error messages
- Gracefully handle expected failure modes
- Log exceptions with stack traces at appropriate levels
This gateway serves as a comprehensive learning resource for BYOVA integration:
- Read the code: Study how the gRPC interfaces are implemented
- Examine connectors: Understand how different voice agent services are integrated
- Follow the patterns: Use the established architectural patterns in your own code
- Reference the interfaces: Use the abstract base classes as contracts for your implementations
When building your own BYOVA integration:
- Fork this repository: Use it as a starting point for your project
- Extract components: Take only the parts you need (e.g., just the base connector interface)
- Customize connectors: Modify existing connectors or create new ones for your vendors
- Adapt the architecture: Use the modular design as inspiration for your system
Important: This gateway is not production-ready. For production use:
- Implement proper security: Add authentication, authorization, and encryption
- Enable JWT validation: Configure JWT token validation for secure gRPC communication (see below)
- Add production monitoring: Implement comprehensive logging, metrics, and alerting
- Handle scaling: Design for horizontal scaling and load balancing
- Add error handling: Implement robust error handling and recovery mechanisms
- Security review: Conduct thorough security reviews before deployment
The gateway includes JWT (JSON Web Token) validation for securing gRPC requests from Webex Contact Center. This should be enabled for production deployments.
Key Features:
- Validates JWT signatures using RSA public keys from Webex identity broker
- Verifies all required claims (issuer, audience, subject, JWT ID, expiration)
- Validates datasource-specific claims (URL and schema UUID)
- Caches public keys for 60 minutes to optimize performance
- Supports optional enforcement for gradual rollout
Configuration in config/config.yaml:
jwt_validation:
enabled: true # Enable JWT validation
enforce_validation: true # Reject invalid tokens (set to false for logging only)
datasource_url: "https://your-gateway.example.com:443" # Must match BYODS registration
datasource_schema_uuid: "5397013b-7920-4ffc-807c-e8a3e0a18f43" # BYOVA schema UUID
cache_duration_minutes: 60 # Public key cache durationImplementation Details:
- Module:
src/auth/jwt_validator.py- Core validation logic - Interceptor:
src/auth/jwt_interceptor.py- gRPC request interceptor - Integration: Automatically loaded in
main.pywhen enabled - Reference: Based on Webex sample Java implementation
Deployment Recommendations:
- Start with
enforce_validation: falseto monitor validation without blocking requests - Verify logs show successful validation for all requests
- Enable
enforce_validation: truefor full security - Monitor for authentication errors and adjust configuration as needed
See README.md for complete JWT authentication documentation and troubleshooting.
To begin development (for learning or building upon this example):
Always use a virtual environment to keep dependencies isolated:
# Create a virtual environment in the project directory
python -m venv venv-
Activate Virtual Environment
You must activate the virtual environment before running any code:
# On macOS/Linux: source venv/bin/activate # On Windows: venv\Scripts\activate
Your command prompt should now show the virtual environment name, e.g.
(venv). -
Install Dependencies
# Make sure you're in the activated virtual environment pip install -r requirements.txt -
Generate gRPC Stubs
python -m grpc_tools.protoc -I./proto --python_out=src/generated --grpc_python_out=src/generated proto/*.proto -
Run the Server
python main.py
-
Access Monitoring Interface
- Open http://localhost:8080 in a browser
This section provides specific guidance for AI agents working with this codebase to ensure effective development and accurate assistance.
When analyzing this codebase as an AI agent:
- Start with the interfaces: Always examine
i_vendor_connector.pyfirst to understand the contract - Follow the data flow: Trace requests from
wxcc_gateway_server.py→virtual_agent_router.py→ specific connectors - Study the generated code: The
src/generated/directory contains the gRPC stubs that define the API contract - Check configuration patterns: Look at
config/config.yamlto understand how connectors are loaded and configured
Adding New Connectors:
- Use existing connectors as templates (e.g.,
local_audio_connector.py) - Ensure all abstract methods from
IVendorConnectorare implemented - Follow the error handling patterns established in existing connectors
- Add appropriate logging and monitoring hooks
Debugging Integration Issues:
- Check the monitoring interface at
/api/debug/sessionsfor real-time session data - Review logs for conversation flow and error conditions
- Verify gRPC message format conversions in
convert_wxcc_to_vendorandconvert_vendor_to_wxcc - Test with the local audio connector first before integrating external services
Code Quality and Standards:
- Follow the established error handling patterns in
error_handling.py - Use the logging patterns demonstrated throughout the codebase
- Maintain the modular architecture when adding new features
- Ensure all new code includes proper docstrings and type hints
- Always check the virtual environment: Remind users to activate
venvbefore running Python code - Verify gRPC stub generation: Ensure proto files are compiled before testing
- Test incrementally: Start with local connector before external integrations
- Use the monitoring interface: Leverage the built-in web interface for debugging
- Follow the established patterns: Don't reinvent architecture - extend what exists
- Missing virtual environment activation: Always check if
venvis activated - Forgotten gRPC compilation: Proto files must be compiled to generate Python stubs
- Configuration mismatches: Ensure connector configs match the expected format in
config.yaml - Interface violations: New connectors must implement ALL methods from
IVendorConnector - Error handling gaps: Follow the established error handling patterns in the codebase
When a user asks to add a new feature:
- Analyze the request: Understand what type of connector or functionality is needed
- Examine existing patterns: Look at similar implementations in the codebase
- Check the interface: Ensure the new feature follows the established
IVendorConnectorcontract - Plan the implementation: Break down the task into logical steps
- Implement incrementally: Start with the core functionality, then add error handling and logging
- Test the integration: Use the monitoring interface and local connector for validation
- Document the changes: Update relevant documentation and add proper docstrings
When debugging issues:
- Check the monitoring interface: Start at
/api/debug/sessionsfor real-time data - Review the logs: Look for error patterns and conversation flow issues
- Verify configuration: Ensure all config values are properly set
- Test with known good data: Use the local connector to isolate issues
- Check gRPC message formats: Verify conversions between WxCC and vendor formats
When explaining concepts to users:
- Start with the architecture: Show how the modular design works
- Use concrete examples: Reference specific files and methods in the codebase
- Explain the data flow: Walk through how requests move through the system
- Highlight best practices: Point out the established patterns and why they exist
- Provide working examples: Give users code they can actually run and test
Key Files to Know:
src/connectors/i_vendor_connector.py- Abstract base class for all connectorssrc/connectors/local_audio_connector.py- Working example connectorsrc/core/wxcc_gateway_server.py- Main gRPC server implementationsrc/core/virtual_agent_router.py- Routes requests to appropriate connectorsconfig/config.yaml- Configuration for connectors and gateway settingsproto/- Protocol buffer definitions for gRPC interfaces
Common Patterns:
- All connectors inherit from
IVendorConnectorand implement its abstract methods - Configuration-driven connector loading in
VirtualAgentRouter - Bidirectional streaming for voice interactions in
ProcessCallerInput - Error handling through dedicated error handling modules
- Monitoring and debugging via web interface at port 8080
Testing Approaches:
- Use local audio connector for initial testing and validation
- Monitor real-time data via
/api/debug/sessionsendpoint - Check logs for conversation flow and error conditions
- Test gRPC message format conversions thoroughly
- Validate configuration changes through the monitoring interface
This BYOVA Gateway serves as a functional example and reference implementation for customers and developers working with BYOVA. It demonstrates:
- Best practices for implementing BYOVA gRPC interfaces
- Modular architecture that can be adapted for different use cases
- Well-documented code that serves as a learning resource
- Extensible connector system that shows how to integrate various voice agent services
Remember: This is not a production-ready application, but rather a comprehensive example that customers can use to understand, learn from, and build upon for their own BYOVA integrations. The code quality, documentation, and architectural patterns are designed to serve as a reference for enterprise-grade BYOVA implementations.
For questions about BYOVA integration or this reference implementation, please refer to the official BYOVA documentation or contact your Webex Contact Center representative.