Resolving Voice Notification Webex Calling SIP Registration

Where does the REGISTER stop between the gateway and Webex Calling?

This installation runs the Voice Notification module on two gateway versions: a legacy 7.9 gateway and an 8.1 gateway. Neither registers as a SIP endpoint with Webex Calling. IT suspected that the module does not support TLS 1.2. The upgrade from 7.9 to 8.1 did not change the result, so a version bump alone does not clear this class of failure.

Follow the packet. The module is the SIP user agent. It sends a REGISTER to the provider's registrar. That request crosses the plant or MES network, the site firewall and NAT, the internet path, and then the cloud edge. A cloud calling service that only accepts SIP over TLS drops the request at its edge if the TLS handshake never completes. In that case the SIP layer never sees a REGISTER, and the module's log reports a timeout or a registration failure with no SIP response code.

Why does a SIP client fail against a TLS-only cloud registrar?

SIP defines three transports. UDP and TCP normally use port 5060, and TLS normally uses port 5061. Many embedded SIP stacks in notification and paging products implement only UDP and TCP, because they were built to register against an on-premises PBX on a trusted LAN. Hosted calling platforms usually require signaling encryption and often require SRTP for media as well. When the client cannot speak the transport the registrar demands, the failure happens below SIP, so SIP-level settings such as credentials, realm, and outbound proxy have no effect.

Three distinct cases produce the same "fails to register" symptom:

• No TLS transport in the SIP stack. The module sends plaintext SIP to 5060, or plaintext to 5061. The cloud edge ignores it or resets the connection.
• TLS offered, wrong version or cipher. A ClientHello goes out, but it advertises only older protocol versions or cipher suites the edge refuses. The edge answers with a TLS alert.
• TLS completes, trust or auth fails. The certificate chain is not in the client's trust store, or the client does not present a certificate the service expects. If the handshake does complete, the SIP digest exchange can still fail.

Only the second case is a "TLS 1.2 support" problem in the narrow sense. The first case is more common for this class of module, and no TLS setting can fix it.

Which captures isolate the failing layer?

Layer one first. Confirm that the gateway host has a route and DNS resolution to the registrar's hostname before you look at protocols. Then run a capture on the gateway host, or on a SPAN port upstream of it, while the module attempts registration.

Set the module's logger to debug or trace in the gateway's logging settings before you capture, so that the SIP stack's transport selection appears alongside the packets.

Which integration path fits: upgrade, SBC, or plain-SIP trunk?

Recommendation: put a session border controller, or a PBX that is certified to register to Webex Calling, between the gateways and the cloud. It decouples the notification pipeline from the SIP stack's transport support. It serves the legacy 7.9 gateway and the 8.1 gateways identically, and it survives the planned move to 8.3 without rework. Open the support case in parallel. If support confirms native TLS/SRTP in a specific release, you can retire the SBC later.

How do I build the SBC path for the notification gateways?

1. Provision the SBC or PBX in Webex Calling using the trunk or local-gateway type that Webex Calling supports. Follow the provider's current documentation for TLS version, certificate, and SRTP requirements.
2. Import the provider's CA chain on the SBC. Confirm that its TLS registration shows as up in the provider portal before you touch the gateways.
3. Create a LAN-side SIP registrar or extension on the SBC for each gateway. Use UDP or TCP on 5060, with digest credentials unique to each gateway.
4. Point each gateway's Voice Notification SIP profile at the SBC's LAN address. Set the transport to UDP or TCP, and enter that extension's credentials.
5. Build the outbound dial rule on the SBC. Route calls originating from the gateway extensions to the Webex trunk, with number normalization in the format the cloud expects.
6. Enable RTP-to-SRTP handling on the SBC for the gateway extensions. Open the SBC's LAN-side RTP port range on any firewall between the gateways and the SBC.
7. Restrict the SBC's LAN SIP listener to the gateway subnet, so the cleartext leg is not exposed beyond the OT segment.

How do I verify the pipeline end to end?

1. Check the module's registration status on each gateway. It must show as registered against the SBC.
2. Capture on the SBC's LAN interface. Confirm REGISTER returns 200 OK and that the Expires refresh repeats before timeout.
3. Capture on the SBC's WAN interface. Confirm that only TLS appears on the signaling port and that no plaintext SIP leaves the site.
4. Trigger a test alarm routed to a voice roster. Confirm the call is placed, the TTS prompt is audible, and acknowledgement digits (DTMF) are received. DTMF is the item most often lost when media is transcoded, so check the SBC's DTMF relay mode if acks fail.
5. Leave the pipeline idle past several registration refresh intervals, then trigger again. This confirms NAT and firewall pinholes hold between calls.

FAQ