Direct Routing SBC + ChatOps Telephony Integration Prompt

You are a senior telephony architect who has designed Direct Routing SBC integrations for Teams that bridge PSTN telephony into ChatOps incident workflows.

I will provide:
- SBC vendor (AudioCodes / Ribbon / Cisco / Avaya / Oracle)
- Existing PSTN provider + dial plan
- ChatOps bot architecture
- Incident management tool
- Disaster recovery requirements

Your job:

1. **Architecture overview**:
   - PSTN provider → SBC → Direct Routing → Teams Phone
   - SBC also routes inbound to IVR (for paging menus)
   - Bot service is in Azure / your cloud, connected to both Teams (for chat) and SBC (for telephony control via SIP REST)

2. **Use cases** — what telephony adds to ChatOps:
   - **PSTN call → page on-call** — customer calls support number; SBC IVR routes to current on-call's Teams Phone
   - **SMS ack** — on-call can ack a page from anywhere via SMS to a dedicated number (SBC SMS handling or carrier SMS-to-API gateway)
   - **Voicemail-to-ticket** — voicemail transcribed, ServiceNow ticket created automatically with audio attached
   - **Incident bridge** — bot dials all on-call humans for a SEV1 conference
   - **DR mode** — when Teams/M365 is down, fallback to PSTN-only paging

3. **SBC configuration patterns**:
   - **Inbound routing**: PSTN number → IVR menu → routing to Teams user (current on-call)
   - **Outbound**: Teams user → SBC → carrier
   - **Failover**: primary SBC, secondary SBC, with health-check failover
   - **Codec selection**: prefer Teams-native codecs (SILK, Opus); fall back to G.711 for PSTN

4. **IVR for paging**:
   - Greeting: "Press 1 for support, 2 for emergency, 3 for after-hours"
   - Routing: query the IM tool API for current on-call → SIP REFER to that user's Teams DID
   - Fallback: if no on-call resolves in 30s → secondary on-call → manager → general voicemail

5. **SMS integration**:
   - Carrier-provided SMS-to-HTTP gateway (Twilio, Vonage, carrier-native)
   - Inbound SMS → webhook → ChatOps bot
   - Bot validates sender (must be registered on-call), acknowledges page in incident system
   - Outbound: bot sends SMS confirmation

6. **Voicemail-to-ticket**:
   - SBC voicemail → audio file + transcription
   - Bot creates ServiceNow / Jira ticket with audio attachment + transcript
   - Routes to appropriate team based on number dialed

7. **Incident bridge automation**:
   - For SEV1, bot dials all required on-calls in parallel via SIP REST to SBC
   - When 2+ answer, conference them into a Teams meeting bridge
   - Records the conference (with consent disclosure)
   - Transcribes for postmortem

8. **DR fallback path**:
   - Synthetic monitor checks Teams reachability
   - If Teams unreachable, switch paging to PSTN-only mode (skip Teams notification, go straight to PSTN call)
   - Bot has direct SBC API access; doesn't depend on Teams to function
   - Status page updates via direct API call

9. **Compliance & legal**:
   - Call recording consent disclosure (varies by jurisdiction)
   - Emergency services (911 / 999 / 112) routing per Direct Routing requirements
   - PCI scope — if any spoken card data possible, exclude or apply PCI controls
   - Retention of voicemail + transcripts per regime

10. **Anti-patterns to avoid**:
   - Single SBC (no DR)
   - Single PSTN provider for emergency paging
   - Untested DR scenarios
   - IVR with too many menus (caller drops at 3+ levels)
   - Voicemail-to-ticket with no human review for sensitive content

Output as: (a) architecture diagram with SBC + Teams + bot, (b) IVR routing flow, (c) SMS integration design, (d) voicemail-to-ticket flow, (e) incident bridge automation, (f) DR runbook for Teams outage, (g) compliance + legal checklist, (h) anti-pattern list.

Bias toward: defense-in-depth (multiple paths), observable telephony, fast IVR, DR fallback that's actually tested.