SIP Trunk Registration Failing with 403 on mypurecloud.jp

Voice & Telephony
1

The outbound SIP trunk registration procedure returns a 403 Forbidden response at 2024-06-12T14:30:00Z. Config looks correct on paper. The carrier proxy doesn’t accept the initial INVITE prior to media negotiation. Apologies for the beginner inquiry, however the endpoint documentation doesn’t specify the required realm format for Japanese carriers.

  • Environment: .jp, 800 agents, multi-site setup
  • SIP Proxy: 10.20.30.45 (internal carrier gateway)
  • SDK: Genesys Cloud Java SDK v1.4.8
  • Timezone handling: Europe/Berlin for admin console, JST for agent desktops
  • Step: PUT /api/v2/telephony/providers/edges/{edgeId}/siptrunks/{sipTrunkId}
    Log output stops halfway through the handshake:
    [2024-06-12T14:30:00.112Z] INFO SipTrunkConfig: Initiating registration…
    [2024-06-12T14:30:00.115Z] WARN HttpTransport: 403 Forbidden - Missing realm parameter…
    [2024-06-12T14:30:00.118Z] DEBUG …
2

The realm field on the .jp environment is notoriously picky. You’ll need to strip the domain suffix and just pass the carrier’s exact SIP domain in lowercase. In CIC we used to hit the same 403 wall with Japanese PSTN gateways when the Attendant config expected a fully qualified realm instead of a plain string.

Grabbed a quick screenshot of the exact field layout below.

Try setting realm to just carrier-proxy.jp and drop the sip: prefix entirely. The outbound registration handshake chokes if the proxy sees extra characters before the auth challenge. Also flip the transport toggle to UDP if it’s currently on TCP. Japanese carriers often drop TCP SYN packets during the initial SIP exchange.

The SDK docs gloss over this regional quirk. Just verify the proxy-host matches exactly. The auth token generation will fail if the realm string throws off the MD5 hash.