openAI real time API with TLS transport

Asterisk AI
1

Hi, i am connecting openAI real time API (via SIP) and asteriskI get some problem in TLS. Anyone have same bug? Am I missing something?

[Sep 12 08:15:27] NOTICE[455] res_pjsip/pjsip_transport_events.c: Transport ‘transport-tls’ to remote ‘``sip.api.openai.com``’ - The certificate is untrusted
[Sep 12 08:15:27] NOTICE[455] res_pjsip/pjsip_transport_events.c: Transport ‘transport-tls’ to remote ‘``sip.api.openai.com``’ - The server identity does not match to any identities specified in the certificate

Here is my pjsip config:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
method=tlsv1_2 
ca_list_file=/var/lib/asterisk/keys/ca.crt
cert_file=/var/lib/asterisk/keys/asterisk.crt
priv_key_file=/var/lib/asterisk/keys/asterisk.key
verify_client=no
verify_server=no 

[openai-aor]
type=aor
qualify_frequency=0
contact=sip:sip.api.openai.com:5061;transport=tls

[openai]
type=endpoint
transport=transport-tls
context=from-internal
disallow=all
allow=ulaw,alaw
aors=openai-aor
;domain=*.api.openai.com 
send_connected_line=no
rtp_keepalive=0
language=en
user_eq_phone=no
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
media_encryption=sdes
rtp_symmetric=yes
dtmf_mode=auto

[openai-identify]
type=identify
endpoint=openai
match=sip.api.openai.com
2

What makes you think that there is a bug in Asterisk? Sounds more like there is an error in Open AI's certificate. Maybe they have used a wildcard, which is not a valid option for SIP. In any case, you have told it to ignore such errors, and it is not reporting it it as an error.

Actually, they seem to be identifying as api.openai.com, but you are trying to connect to sip.api.openai.com so the server name definitely isn’t in the certificate. It does have *.api.openai.com as an alternative name, but that’s a wildcard, and they are not allowed for SIP.

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
dd:56:8b:95:4f:f7:5b:05:11:a8:4f:f3:0d:59:dc:80
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = US, O = Google Trust Services, CN = WE1
Validity
Not Before: Jul 18 23:58:22 2025 GMT
Not After : Oct 17 00:58:20 2025 GMT
Subject: CN = ``api.openai.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:30:f8:b5:5b:ed:ff:29:46:97:70:4f:a6:49:6b:
ee:96:a9:b3:bc:9a:67:e9:a7:66:b9:e6:d1:d2:6a:
69:2a:a2:f3:90:af:e4:8d:26:6d:db:5e:cd:1d:d9:
e2:be:3b:bc:c8:05:bc:db:af:82:e2:a1:30:80:b8:
52:ac:1c:2f:b7
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
48:29:2B:02:21:CF:C4:6D:D2:39:62:29:72:4D:08:BE:79:BA:74:A8
X509v3 Authority Key Identifier:
90:77:92:35:67:C4:FF:A8:CC:A9:E6:7B:D9:80:79:7B:CC:93:F9:38
Authority Information Access:
OCSP - URI:``http://o.pki.goog/s/we1/3VY
CA Issuers - URI:``http://i.pki.goog/we1.crt
X509v3 Subject Alternative Name:
DNS:api.openai.com, DNS:*.api.openai.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:``http://c.pki.goog/we1/KAimmlFj7xM.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 12:F1:4E:34:BD:53:72:4C:84:06:19:C3:8F:3F:7A:13:
F8:E7:B5:62:87:88:9C:6D:30:05:84:EB:E5:86:26:3A
Timestamp : Jul 19 00:58:23.584 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:A5:63:41:F1:7C:50:1A:52:74:C9:86:
4D:45:D3:C4:17:A3:D1:CC:DE:77:7E:14:6C:EC:1F:9A:
21:BE:08:E7:EE:02:21:00:9C:3B:A1:32:B0:6C:89:AD:
44:52:F0:DE:CF:F1:6B:A3:56:32:F1:8E:91:E4:81:04:
73:BE:FC:C9:E0:07:F8:D5
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 0D:E1:F2:30:2B:D3:0D:C1:40:62:12:09:EA:55:2E:FC:
47:74:7C:B1:D7:E9:30:EF:0E:42:1E:B4:7E:4E:AA:34
Timestamp : Jul 19 00:58:24.595 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:EA:D8:B4:D4:B6:85:6A:69:49:01:CE:
79:A1:DC:BC:54:66:B7:A6:3E:E8:80:D3:5C:E8:A7:30:
94:60:44:D9:D0:02:20:0F:07:32:EB:56:0D:96:49:AE:
24:23:79:A6:E0:04:B0:47:35:8C:3C:C5:23:DE:6A:8F:
D0:A1:A0:10:85:7C:F7
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:44:02:20:04:d5:4c:12:e4:ea:4a:d9:4f:28:2b:65:4b:ef:
3b:79:cf:9e:69:92:ea:e6:2b:3a:84:43:63:bc:31:a0:61:66:
02:20:1e:24:c3:14:c2:5c:a3:f7:ec:57:5f:e0:5d:3f:de:bb:
99:3c:14:ee:9b:b8:1a:55:c1:37:c9:58:a5:84:25:5c

There are some stray double back ticks in the above, which seem to result from my terminal program marking things as links, and the forum preformatted text function getting confused.

3

If “verify_server” is set to “no”, which according to the provided configuration it is then we don’t care about the verification result and won’t stop the connection.

Aside from the notices, what is actually going on (if anything)?

4

Hi @jsonchan000 ,

Instead of trying to register OpenAI directly as a SIP endpoint, you might consider using AgentVoiceResponse. AVR integrates with Asterisk through the AudioSocket module, so you don’t have to deal with SIP/TLS certificate mismatches against OpenAI.

AVR already supports OpenAI Realtime out of the box, and you can easily set it up with the provided docker-compose-openai-realtime.yml. Inside that compose, there’s also an Asterisk service ready to connect to AVR. If you already have your own Asterisk instance, you can integrate it simply with an extension like:

exten => s,1,Answer()
 same => n,Ringing()
 same => n,Wait(1)
 same => n,Set(UUID=${SHELL(uuidgen | tr -d '\n')})
 same => n,Dial(AudioSocket/AVR_CORE_IP:AVR_CORE_PORT/${UUID})
 same => n,Hangup()

This way you can stream audio reliably between Asterisk and OpenAI without touching SIP/TLS directly.

Have a look here:

Let me know if you try this approach — happy to help further!

I’d also recommend joining our Discord community, where many members share their setups and might have already solved the same issue you’re experiencing.