|
| 1 | +```md |
| 2 | +# SIP Trunk Interconnection – Technical Handover Document |
| 3 | + |
| 4 | +**Deployment Environment:** Microsoft Azure (AKS) |
| 5 | +**Connection Type:** Site-to-Site IPsec VPN (IKEv2) |
| 6 | +**Use Case:** AI-powered voice call handling (server-side SIP) |
| 7 | + |
| 8 | +--- |
| 9 | + |
| 10 | +## 1. Purpose of This Document |
| 11 | + |
| 12 | +This document defines the technical requirements, network configuration, and operational expectations for establishing a **secure SIP trunk connection** between the SIP Trunking Provider and the **Pipecat Voice Agent Platform**. |
| 13 | + |
| 14 | +It is intended as a **handover and onboarding reference** for network and voice engineering teams on the provider side. |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## 2. Solution Overview |
| 19 | + |
| 20 | +The Pipecat Voice Platform terminates both **SIP signaling and RTP media server-side** within a private Azure environment. |
| 21 | + |
| 22 | +Key characteristics: |
| 23 | + |
| 24 | +- SIP and RTP are transported via a **private IPsec VPN tunnel** |
| 25 | +- No public SIP exposure |
| 26 | +- No WebRTC, ICE, or TURN servers involved |
| 27 | +- Designed for high-throughput, low-latency AI call handling |
| 28 | + |
| 29 | +--- |
| 30 | + |
| 31 | +## 3. High-Level Architecture |
| 32 | + |
| 33 | +``` |
| 34 | + |
| 35 | +SIP Provider Network |
| 36 | +| |
| 37 | +IPsec VPN (IKEv2) |
| 38 | +| |
| 39 | +Azure VPN Gateway |
| 40 | +| |
| 41 | +Azure Virtual Network |
| 42 | +| |
| 43 | +AKS Ingress |
| 44 | +| |
| 45 | +Pipecat Voice Agent |
| 46 | +(SIP + RTP termination) |
| 47 | + |
| 48 | +``` |
| 49 | +
|
| 50 | +All signaling and media traffic remains inside private networks. |
| 51 | +
|
| 52 | +--- |
| 53 | +
|
| 54 | +## 4. VPN Configuration (Mandatory) |
| 55 | +
|
| 56 | +### 4.1 VPN Type |
| 57 | +
|
| 58 | +| Item | Value | |
| 59 | +|----|-----| |
| 60 | +| VPN Type | Site-to-Site | |
| 61 | +| Routing | Route-based | |
| 62 | +| IKE Version | IKEv2 | |
| 63 | +
|
| 64 | +--- |
| 65 | +
|
| 66 | +### 4.2 IPsec / IKE Security Parameters |
| 67 | +
|
| 68 | +The following parameters must be supported and configured on the provider side: |
| 69 | +
|
| 70 | +| Parameter | Value | |
| 71 | +|--------|------| |
| 72 | +| IKE Encryption | AES-256 | |
| 73 | +| IKE Integrity | SHA-256 | |
| 74 | +| Diffie-Hellman Group | DH Group 14 | |
| 75 | +| IPsec Encryption | AES-256 | |
| 76 | +| IPsec Integrity | SHA-256 | |
| 77 | +| Perfect Forward Secrecy | PFS Group 14 | |
| 78 | +| Security Association Lifetime | 3600 seconds | |
| 79 | +
|
| 80 | +> **Note:** Weak or legacy ciphers (AES128, SHA1, DH2/DH5) are not permitted. |
| 81 | +
|
| 82 | +--- |
| 83 | +
|
| 84 | +### 4.3 Information Required From SIP Provider |
| 85 | +
|
| 86 | +To complete VPN provisioning, the following details are required: |
| 87 | +
|
| 88 | +- VPN gateway **public IP address** |
| 89 | +- Internal **SIP/RTP CIDR ranges** |
| 90 | +- Preferred **Pre-Shared Key (PSK)** |
| 91 | +- Supported RTP port range (if fixed) |
| 92 | +
|
| 93 | +--- |
| 94 | +
|
| 95 | +## 5. SIP Signaling Configuration |
| 96 | +
|
| 97 | +### 5.1 Transport |
| 98 | +
|
| 99 | +| Item | Value | |
| 100 | +|---|---| |
| 101 | +| Primary Transport | SIP over WebSocket (WSS) | |
| 102 | +| Alternative | SIP over TCP | |
| 103 | +| SIP TLS | Supported | |
| 104 | +
|
| 105 | +> SIP over UDP is supported only if explicitly required. |
| 106 | +
|
| 107 | +--- |
| 108 | +
|
| 109 | +### 5.2 SIP Trunk Characteristics |
| 110 | +
|
| 111 | +| Parameter | Value | |
| 112 | +|--------|------| |
| 113 | +| SIP Port | 5061 (TLS) or WSS endpoint | |
| 114 | +| Registration | Static trunk (no REGISTER) | |
| 115 | +| Authentication | IP-based (VPN-scoped) | |
| 116 | +| SIP Domain | Provided during onboarding | |
| 117 | +
|
| 118 | +--- |
| 119 | +
|
| 120 | +## 6. Media (RTP) Configuration |
| 121 | +
|
| 122 | +### 6.1 Media Handling Model |
| 123 | +
|
| 124 | +- RTP media is **terminated directly by Pipecat** |
| 125 | +- No media relay services (TURN) are used |
| 126 | +- Media remains inside the IPsec tunnel |
| 127 | +
|
| 128 | +--- |
| 129 | +
|
| 130 | +### 6.2 RTP Transport Details |
| 131 | +
|
| 132 | +| Item | Value | |
| 133 | +|----|----| |
| 134 | +| Protocol | RTP / SRTP | |
| 135 | +| Transport | UDP | |
| 136 | +| Direction | Bidirectional | |
| 137 | +| NAT Traversal | Not required | |
| 138 | +
|
| 139 | +--- |
| 140 | +
|
| 141 | +### 6.3 RTP Port Range |
| 142 | +
|
| 143 | +A configurable RTP port range will be allocated, for example: |
| 144 | +
|
| 145 | +``` |
| 146 | + |
| 147 | +UDP 20000–40000 |
| 148 | + |
| 149 | +``` |
| 150 | +
|
| 151 | +Exact values will be confirmed during provisioning. |
| 152 | +
|
| 153 | +--- |
| 154 | +
|
| 155 | +## 7. Network & Firewall Requirements |
| 156 | +
|
| 157 | +### 7.1 SIP Provider Requirements |
| 158 | +
|
| 159 | +Allow outbound traffic to: |
| 160 | +
|
| 161 | +- Azure VPN Gateway public IP |
| 162 | +- SIP signaling ports (TLS/WSS) |
| 163 | +- RTP UDP port range |
| 164 | +
|
| 165 | +--- |
| 166 | +
|
| 167 | +### 7.2 Azure-Side Controls |
| 168 | +
|
| 169 | +- SIP traffic allowed **only from VPN CIDRs** |
| 170 | +- Network Security Groups enforce SIP/RTP rules |
| 171 | +- Web Application Firewall protects signaling endpoints |
| 172 | +- No public SIP exposure |
| 173 | +
|
| 174 | +--- |
| 175 | +
|
| 176 | +## 8. Call Flow Summary |
| 177 | +
|
| 178 | +### 8.1 Incoming Call Flow |
| 179 | +
|
| 180 | +1. SIP Provider sends `INVITE` over IPsec VPN |
| 181 | +2. SIP signaling reaches AKS Ingress |
| 182 | +3. Pipecat Voice Agent accepts and negotiates media |
| 183 | +4. RTP flows directly over IPsec |
| 184 | +5. Audio is processed by AI agent |
| 185 | +
|
| 186 | +--- |
| 187 | +
|
| 188 | +### 8.2 Media Processing |
| 189 | +
|
| 190 | +- Audio streamed into AI pipeline |
| 191 | +- Real-time responses generated |
| 192 | +- RTP audio returned to SIP provider |
| 193 | +
|
| 194 | +--- |
| 195 | +
|
| 196 | +## 9. Reliability & Scaling |
| 197 | +
|
| 198 | +- Pipecat runs as stateless Kubernetes pods |
| 199 | +- Horizontal scaling supported |
| 200 | +- Call/session state managed via internal Redis |
| 201 | +- No dependency on client-side state |
| 202 | +
|
| 203 | +--- |
| 204 | +
|
| 205 | +## 10. Monitoring & Troubleshooting |
| 206 | +
|
| 207 | +- SIP signaling logs available on request |
| 208 | +- RTP metrics: packet loss, jitter, latency |
| 209 | +- VPN tunnel health monitored continuously |
| 210 | +- Maintenance windows communicated in advance |
| 211 | +
|
| 212 | +--- |
| 213 | +
|
| 214 | +## 11. Security Considerations |
| 215 | +
|
| 216 | +- All traffic encrypted via IPsec |
| 217 | +- No public SIP endpoints |
| 218 | +- IP whitelisting enforced |
| 219 | +- Credentials never transmitted via SIP headers |
| 220 | +
|
| 221 | +--- |
| 222 | +
|
| 223 | +## 12. Onboarding & Testing |
| 224 | +
|
| 225 | +During onboarding, the following steps will be coordinated: |
| 226 | +
|
| 227 | +1. Exchange network and VPN parameters |
| 228 | +2. Bring up IPsec tunnel |
| 229 | +3. Validate SIP registration / trunk connectivity |
| 230 | +4. Execute test calls (signaling + media) |
| 231 | +5. Move to production traffic |
| 232 | +
|
| 233 | +A staging environment can be provided if required. |
| 234 | +
|
| 235 | +--- |
| 236 | +
|
| 237 | +## 13. Contact & Coordination |
| 238 | +
|
| 239 | +For provisioning, testing, or operational coordination, a dedicated technical contact will be assigned during onboarding. |
| 240 | +
|
| 241 | +--- |
| 242 | +
|
| 243 | +**End of Document** |
| 244 | +``` |
0 commit comments