OpenAI mở gọi SIP ra ngoài cho mọi tổ chức qua Live API

OpenAI vừa công bố tính năng gọi SIP ra ngoài (outbound SIP calling) đã sẵn sàng cho tất cả các tổ chức, thông qua Live API chứ không phải endpoint tạo cuộc gọi của Realtime API. Đây là bước tiến quan trọng để các doanh nghiệp xây dựng tổng đài AI có thể chủ động gọi điện tới khách hàng thay vì chỉ nhận cuộc gọi đến.

Cách hoạt động

SIP (Session Initiation Protocol) là giao thức dùng để thực hiện cuộc gọi điện thoại qua internet. Với tính năng mới, nhà cung cấp dịch vụ SIP trunk — ví dụ Twilio — sẽ xử lý kết nối tới mạng điện thoại, trong khi mô hình GPT-Live đảm nhận phần hội thoại.

Để đặt cuộc gọi ra ngoài, lập trình viên gửi yêu cầu POST /v1/live/sessions với cấu hình phiên và transport.type: "sip". Khác với cuộc gọi đến, quy trình này không cần webhook live.transport.incoming hay yêu cầu chấp nhận cuộc gọi.

Cấu hình trunk bao gồm các trường chính:

• transport.destination: số điện thoại cần gọi, định dạng E.164, ví dụ +14155550123. Không hỗ trợ đích dạng SIP URI.
• transport.trunk.provider_url: endpoint của nhà cung cấp, ví dụ sips:sip.example.com:5061. Cổng mặc định là 5061, và endpoint bắt buộc dùng sips: để bảo đảm tín hiệu qua TLS.
• transport.trunk.auth: xác thực kiểu digest với username và password của nhà cung cấp SIP.
• transport.trunk.caller_number: số điện thoại người gọi hiển thị cho nhà cung cấp, định dạng E.164.

Trunk cần hỗ trợ tín hiệu TLS và truyền tải media bằng SDES-SRTP. OpenAI lưu ý không đưa thông tin xác thực, đường dẫn hay tham số URI vào URL, đồng thời từ chối các hostname nội bộ và địa chỉ IP riêng. Khóa API OpenAI và thông tin SIP phải được giữ trên server.

Theo dõi và kết thúc cuộc gọi

Sau khi tạo phiên, backend kết nối tới wss://api.openai.com/v1/live/sessions/{session_id}/attach — được gọi là sideband — để nhận sự kiện hội thoại và điều khiển cuộc gọi, trong khi SIP vẫn truyền tải âm thanh. Kết nối này cần được thực hiện ngay lập tức, vì sideband chỉ phát lại các sự kiện trong 3 giây trước đó.

Các sự kiện tiến trình cuộc gọi gồm:

• transport.ringing: nhà cung cấp báo chuông hoặc media sớm.
• transport.answered: cuộc gọi đã được nhấc máy và media đã thiết lập.
• transport.failed: thiết lập cuộc gọi thất bại sau khi khởi tạo phiên.

Thời gian đổ chuông tối đa là 3 phút và cuộc gọi đã kết nối tối đa 2 giờ, không thể tùy chỉnh khi tạo phiên. Lỗi cấu hình phiên trả về ngay ở yêu cầu tạo, trong khi lỗi thiết lập truyền tải có thể trả về mã 502 và hết thời gian khởi tạo trả về 504.

Điều khiển cuộc gọi đang hoạt động

Các điều khiển này áp dụng cho cả cuộc gọi SIP đến và đi. Backend có thể gửi và nhận sự kiện bàn phím qua transport.dtmf.send và transport.dtmf.received, chuyển cuộc gọi bằng POST /v1/live/sessions/{session_id}/refer với target_uri, hoặc ngắt cuộc gọi bằng endpoint hangup.

Một lưu ý quan trọng về bảo mật: OpenAI khuyến nghị coi sip_headers là dữ liệu người gọi không đáng tin cậy, không phải cơ chế xác thực. Ngoài ra, để tránh thực thi công cụ hai lần, mỗi hành động chỉ nên gán cho một handler duy nhất, kể cả khi sự kiện xuất hiện trên nhiều kết nối.

Yêu cầu mạng

Cuộc gọi SIP của GPT-Live dùng đường mạng riêng cho tín hiệu và media. Với tín hiệu SIP, cần cho phép lưu lượng TCP/TLS ra ngoài tới các endpoint sip.api.openai.com và sip-eu.api.openai.com (định tuyến theo GeoIP) trên cổng 5061. Với media SRTP, cần cho phép lưu lượng UDP hai chiều tới các dải CIDR: 13.79.45.80/28, 23.98.140.64/28, 40.67.149.176/28 và 40.83.204.240/28.

Góc nhìn

Với các lập trình viên và doanh nghiệp Việt Nam xây dựng tổng đài AI, việc outbound SIP được mở cho mọi tổ chức nghĩa là có thể tự động hóa các cuộc gọi như xác nhận lịch hẹn, nhắc nợ hay chăm sóc khách hàng mà không cần thêm một nhà cung cấp giải pháp trung gian. Rào cản kỹ thuật chính nằm ở việc cấu hình firewall để mở đúng dải IP cho SRTP và đảm bảo kết nối TLS tới trunk — những việc đội hạ tầng cần phối hợp chặt với nhà cung cấp SIP.

Một điểm cần lưu tâm là giới hạn 2 giờ mỗi cuộc gọi và yêu cầu xử lý chống trùng sự kiện, vì vậy kiến trúc backend cần thiết kế sẵn cơ chế deduplication theo event_id ngay từ đầu thay vì bổ sung sau. Việc xử lý sip_headers như dữ liệu không đáng tin cậy cũng là bài học bảo mật cần áp dụng nghiêm túc khi tích hợp với các hệ thống CRM nội bộ.