Setting up SIP Link requires a complex series of integrations. Use this article to help troubleshoot during the integration process.
Before you begin
To troubleshoot SIP Link, make sure you have:
- Packet Capture on your SBC
- Packet Capture on your Firewall
- A tool to view packet captures
- Access to your SBC logs
Note: If you need additional help with troubleshooting, contact your SBC vendor or carrier.
Confirm signal connection with SIP Link
Signaling for SIP Link uses Transport Layer Security (TLS). TLS consists of a package of certificates created by public Certificate Authorities (CA). You can check the status of your TLS connection from the admin control panel SIP Link landing page.
- Confirm your TLS certificate is from one the following CAs:
- DigiCert
- Entrust DataCard
- GlobalSign
- GoDaddy
- Sectigo
- Start a 3-way Transmission Control Protocol (TCP) handshake, followed by a TLS handshake.
When the certificates exchange, Voice sends a certificate followed by the SBC’s certificates.
- Once this exchange takes place, application data can be exchanged between Voice and your SBC.
Troubleshoot call quality
If you’re having issues with call quality, make sure your network latency is consistent and low. Call quality is at its best when Voice traffic takes the shortest path between Voice and the SBC. Your goal should be a round-trip latency of 100 ms or less.
To test network latency:
- Ping the Voice media front-end server from the SBC’s external interface.
- Remain connected to Voice for at least 4 hours.
- Make sure your latency is consistent and 100 ms or less. Don’t average the latency value and check for occasional latency spikes.
- If your latency is not 100 ms or less, use the traceroute utility to print the network path from your SBC or client machine to the Voice media front-end. The path should be as short as possible, for example:
- For desktop, use > traceroute lens.voice.google.com or > traceroute 74.125.39.139
- For Chromebooks, use > tracepath lens.voice.google.com
- For SBCs, use traceroute siplink.telephony.goog or traceroute lens.voice.google.com
Troubleshoot common signal connection issues
Can’t establish TCP session between SBC and Voice
If your TCP session isn’t establishing, it could be due to a firewall or network connectivity issue. The SBC may send a SYN message, but there’s no response.
To resolve this issue,
- Ping siplink.telephony.google to ensure network connectivity is available.
- Enable destination port 5672 for Voice.
- Confirm DNS is functioning for the siplink.telephony.goog resolution.
- Check that your firewall allows traffic from SBC, and that the siplink.telephony.goog:5672 port is open.
Can’t establish TLS session between SBC and Voice
To resolve this issue,
- Ensure your root certificate and Intermediate certificate associated with the PCA is uploaded in the key store associated with your TLS profile for SIP Link. When generating the CSR for the SBC’s certification, please follow the guidelines in the interop document for your respective SBC vendor.
- Make sure your SBC cert follows these guidelines:
- 2,048 key size
- RSA or ECDSA encryption
- The common name (CN) matches the host name created for SIP Link
- The domain of the CN in the certificate matches the Workspace domain
- Mutual authentication enabled
- Server & client authentication enabled
- Wildcard certificates are not supported
- Make sure that Google’s certification GTSR1 found at pki.goog is also uploaded in the key store for its respective TLS profile for SIP Link.
- Check if the certificate validity from the SBC to Google has lapsed.
404 or 604 Not Found response during SBC invite
If you get a 404 or 604 Not Found response during the invite from the SBC, you may not have the SBC number assigned to Voice.
To resolve this issue,
- Ensure that the phone number for the SBC is assigned to a user, auto attendant, or ring group in Voice.
- Confirm that the phone number is in E. 164 format in the PAI header.
400 Bad Request response during SBC invite
If you get a 400 Bad Request response during the invite from the SBC, you might not be using the correct secret key.
To resolve this issue,
- Check the Invite message to make sure it contains your X-Google-Pbx-Trunk-Secret-Key SIP header with the correct value. This key is generated when you set up SIP Link.
- Confirm the phone number is in E. 164 format in the P-Asserted-Identity header.
403 Forbidden response from Voice
Troubleshoot common media connection issues
Before you begin troubleshooting your media connection, make sure your network satisfies the following conditions:
- Your network is using Datagram Transport Layer Security (DTLS) or Session Description Protocol Security Description for Media Streams (SDES) encryption, but not both.
- You’re not using unencrypted SDP offers. Calls made this way are automatically terminated.
- MKI or Crypto Lifetime must are disabled.
- If using DTLS, it’s using a self-signed cert on the SBC. The cert does not need to be a CA signed cert.
- Ensure that one of the supported codecs are configured in the Voice profile of your SBC, G711 mulaw (PCMU), G711 alaw (PCMA), Opus, or G722.
- Dual tone multi-frequency (DTMF) is present as telephony events.
- Assign a dedicated Public IP to your SBC’s external interface.
- Configure the Source and Destination NAT for your firewall.
Certificate negotiation failed (DTLS)
If you get an alert message (Level: Fatal, Description: Unknown CA), the certificate used for the DTLS might not be certified.
DTLS negotiation starts with a certificate handshake between the media endpoints specified in the offer and answer SDP connection fields. Once successful, media will flow between SBC and Google Voice over an encrypted connection.
To resolve the issue, make sure the certificate has a self-signed certificate from the SBC. Do not use certificates signed by a public CA because it will lead to fragmentation over UDP that causes issues.
Client Hello messages from SBC to Voice with no response (DTLS)
You may receive several Client Hello messages from the SBC to Voice with no response when using DTLS encryption.
To resolve the issue,
- Check your firewall ports to ensure the SBC has bidirectional media flow to the Voice media IP subnet (74.125.39.0/24) port 19305 or 26500.
- For SBC Public IP:media port <> 74.125.39.0/24:(19302-19308, 26500). Refer to the firewall port section for SIP Link for more information.
- Google Voice Media IPs are reachable by ping and can be tested that way for reachability from the SBC.
I get no response for UDP from SBC to Voice
To resolve the issue,
- Check the firewall ports to ensure the SBC has bidirectional media flow to the Voice media IP subnet (74.125.39.0/24) port 19305 or 26500.
- For SBC Public IP:media port <> 74.125.39.0/24:(19302-19308, 26500). Refer to the firewall port section for SIP Link for more information.
- Google Voice Media IPs are reachable by ping and can be tested that way for reachability from the SBC.
- When performing Network Address Translation (NAT) the firewall shouldn’t modify the port being sent by the SBC. This will make Voice drop the sent media packet from the SBC, as it will see the source as the public IP of the SBC but a different port from the negotiated SDP offer & answer.
Bidirectional packet flow, but no audio on call
Google responds to invite with 486 (SDES)
If the invitation contains MKI, which is not supported by SIP Link, disable MKI.
Related topics
Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.
