Debugging SIP REFER Method Failures during Blind Transfer Operations in Genesys Cloud Contact Center Edge

What This Guide Covers

This guide details the systematic process for diagnosing and resolving SIP REFER method failures that occur when agents perform blind transfers to external destinations through a Genesys Cloud Contact Center Edge deployment. You will configure Edge SIP trunk parameters, validate Architect transfer block behavior, decode SIP signaling flows using Edge trace captures, and align carrier SBC expectations with Genesys B2BUA routing logic. The end result is a fully compliant blind transfer pipeline that successfully routes REFER requests, returns 202 Accepted responses, and completes the re-INVITE without call drops or silent failures.

Prerequisites, Roles & Licensing

• Licensing Tier: Genesys Cloud CX 1, CX 2, or CX 3 with the Contact Center Edge (CCE) add-on. Edge hardware or virtual appliance must be provisioned and registered to the organization.
• Admin Permissions:
  • Telephony > SIP Trunks > Edit
  • System > Edge > Edit
  • Architect > Flows > Edit
  • System > Security > OAuth Client > Edit (if using API automation)
• OAuth Scopes: telephony:trunk:read, telephony:trunk:write, architect:flow:read, edge:config:read
• External Dependencies:
  • Carrier SIP trunk or SBC with REFER method support enabled
  • PCAP/SIP trace access on the Edge appliance (requires edge:trace:read or physical console access)
  • DNS SRV/A record resolution for external SIP domains
  • Network path allowing UDP/TCP port 5060-5061 and media ports (10000-20000) without SIP ALG interference

The Implementation Deep-Dive

1. Validate Edge SIP Trunk B2BUA & REFER Handling Configuration

The Contact Center Edge terminates external SIP trunks and operates as a Back-to-Back User Agent. When a blind transfer occurs, the Edge must accept the REFER request from the internal agent endpoint, strip the internal SIP domain, normalize the target URI, and forward the REFER to the external carrier. Misconfigured B2BUA boundaries cause the Edge to reject the REFER or drop the dialog before re-INVITE generation.

Navigate to Admin > Telephony > SIP Trunks and select the trunk routed through the Edge. Verify the following configuration keys:

• Trunk Type: Set to SIP (not PRI or WebRTC)
• B2BUA Mode: Enable Full B2BUA to ensure the Edge isolates the agent leg from the carrier leg
• REFER Support: Set to Enabled with Allow Blind Transfer checked
• SIP URI Format: Configure Outbound URI Format as sip:{number}@{sip_domain} to match carrier expectations
• Dialog Timeout: Set Invite Timeout to 30s and Refer Timeout to 15s

Execute the following API call to verify the trunk configuration programmatically:

GET /api/v2/telephony/sip/trunks/{trunkId}
Authorization: Bearer {access_token}

The response JSON must contain the following structure:

{
  "id": "trunk_edge_01",
  "name": "Edge Carrier Trunk",
  "type": "SIP",
  "sipUri": "sip:edge-trunk@carrier.example.com",
  "b2bua": true,
  "referSupported": true,
  "blindTransferAllowed": true,
  "outboundUriFormat": "sip:{number}@{sip_domain}",
  "timeouts": {
    "invite": 30,
    "refer": 15
  }
}

The Trap: Leaving B2BUA disabled or setting Refer Timeout below 10s causes the Edge to treat the transfer as a direct proxy operation. The carrier SBC rejects the REFER because the From header still contains the internal Genesys domain, triggering a 403 Forbidden or 481 Call/Transaction Does Not Exist. The architectural reasoning for enforcing Full B2BUA is isolation: the Edge must rewrite SIP headers between legs, enforce media transcoding if required, and guarantee that internal topology never leaks to the carrier.

2. Configure Architect Transfer Blocks for Blind SIP REFER Compliance

Architect flows dictate how the platform generates the SIP REFER request. The transfer block must explicitly specify Blind transfer type, enforce correct URI normalization, and define a fallback route when the REFER fails. Architect does not automatically convert internal extension formats to carrier-compatible SIP URIs.

Open Architect > Flows, locate the transfer block handling external routing, and verify:

• Transfer Type: Blind
• Destination Format: SIP URI
• URI Template: sip:{transfer_to}@{carrier_domain}
• Fallback Flow: Route to a Queue or Play Message block instead of Hangup
• SIP Header Injection: Add P-Asserted-Identity: sip:{agent_id}@{internal_domain} if carrier requires origination verification

Export the flow segment to validate the JSON structure:

GET /api/v2/architect/flows/{flowId}/versions/latest
Authorization: Bearer {access_token}

The transfer block payload must match:

{
  "type": "TRANSFER",
  "settings": {
    "transferType": "BLIND",
    "destinationFormat": "SIP_URI",
    "uriTemplate": "sip:{transfer_to}@carrier.example.com",
    "fallbackFlowId": "flow_fallback_01",
    "sipHeaders": {
      "P-Asserted-Identity": "sip:{agent_id}@internal.genesys.cloud"
    }
  }
}

The Trap: Using Direct Routing or Extension as the destination format forces Architect to generate a REFER with an internal URI like sip:agent123@gen-api.genesyscloud.com. The Edge B2BUA cannot resolve this externally, and the carrier returns 404 Not Found. Architect requires explicit SIP URI templating for external transfers. The architectural reasoning is determinism: the platform must know exactly how to rewrite the Referred-To header before the Edge receives it. Implicit routing relies on DNS NAPTR records that carriers frequently block for security compliance.

3. Implement SIP URI Normalization & Dial Plan Routing for Referred-To Targets

The Edge appliance evaluates incoming REFER requests against the local dial plan before forwarding them. If the Referred-To URI contains characters, prefixes, or domain mismatches, the Edge drops the request silently. URI normalization must strip +, 0, or 1 prefixes, enforce E.164 formatting, and validate against the carrier’s accepted number range.

Configure the Edge dial plan via Admin > Telephony > Edge > Dial Plan:

• Normalization Rule: REGEX_REPLACE(^\\+|\\b0\\b|\\b1\\b, "", $uri)
• E.164 Validation: Enable Strict E.164 with Length: 10-15 digits
• Domain Mapping: Set Outbound Domain to carrier.example.com
• Fallback Behavior: Return 486 Busy Here instead of 404 Not Found to preserve dialog state

Apply the configuration via API:

PUT /api/v2/edge/sites/{siteId}/dial-plan
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "normalization": {
    "regexPattern": "^(\\+|0|1)?([2-9]\\d{2})(\\d{7})$",
    "replacementFormat": "+1$2$3",
    "strictE164": true
  },
  "outboundDomain": "carrier.example.com",
  "fallbackResponse": "486"
}

The Trap: Allowing non-E.164 formats or disabling strict validation causes the Edge to forward malformed URIs to the carrier. The SBC rejects the REFER with 400 Bad Request, but the Edge does not log the rejection because it assumes the carrier will handle normalization. The architectural reasoning for strict E.164 enforcement is carrier compliance: modern SBCs enforce ITU-T E.164 for all REFER transactions to prevent routing loops and fraud. The Edge must sanitize the URI before it crosses the B2BUA boundary.

4. Capture & Decode SIP REFER/202 Accepted Flow via Edge SIP Trace

When blind transfers fail, the failure point exists in the SIP dialog lifecycle. You must capture the exact REFER request, the 202 Accepted response, and the subsequent re-INVITE. Edge appliances provide SIP trace logs that record raw SIP messages with transaction IDs, sequence numbers, and header payloads.

Enable trace capture:

POST /api/v2/edge/sites/{siteId}/traces/sip
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "durationSeconds": 120,
  "captureOptions": {
    "includeHeaders": true,
    "includePayloads": false,
    "filterUri": "sip:*@carrier.example.com"
  }
}

Download the trace and decode the flow. A successful blind transfer exhibits this sequence:

1. Agent Endpoint → Edge: REFER sip:target@carrier.example.com SIP/2.0
2. Edge → Agent Endpoint: SIP/2.0 202 Accepted
3. Edge → Carrier: REFER sip:target@carrier.example.com SIP/2.0 with Referred-To: <sip:target@carrier.example.com>
4. Carrier → Edge: SIP/2.0 202 Accepted
5. Edge → Agent Endpoint: SIP/2.0 487 Request Terminated (agent hangs up)
6. Carrier → Edge: INVITE sip:target@carrier.example.com SIP/2.0 (re-INVITE)
7. Edge → Carrier: SIP/2.0 100 Trying, 180 Ringing, 200 OK

If step 2 or 4 returns 403, 405, or 481, the REFER was rejected. If step 6 never occurs, the carrier accepted the REFER but failed to initiate the re-INVITE.

The Trap: Analyzing only the Genesys Cloud call recordings or Architect flow logs misses the actual SIP transaction. Cloud logs show Transfer Failed but do not expose carrier SBC rejections. The architectural reasoning for Edge-level SIP tracing is visibility: the B2BUA sits at the exact boundary where internal signaling becomes external signaling. You cannot debug REFER failures without observing the raw SIP exchange at that boundary.

5. Diagnose Carrier SBC REFER Rejection & Timeout Behaviors

Carrier SBCs frequently implement security policies that block REFER requests from unknown sources, require specific User-Agent strings, or enforce dialog state verification. When the Edge forwards a REFER, the SBC may return 403 Forbidden due to missing P-Asserted-Identity, 405 Method Not Allowed if REFER is disabled on the trunk, or 481 Call/Transaction Does Not Exist if the SBC lost dialog state due to NAT timeout.

Validate SBC compatibility by sending a test REFER:

POST /api/v2/telephony/sip/trunks/{trunkId}/test-refer
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "targetUri": "sip:5551234567@carrier.example.com",
  "headers": {
    "P-Asserted-Identity": "sip:test@edge.internal",
    "User-Agent": "GenesysEdge/1.0"
  }
}

Review the SBC response codes:

• 202 Accepted: REFER allowed, re-INVITE expected
• 403 Forbidden: Missing authentication or blocked IP range
• 405 Method Not Allowed: REFER disabled on carrier side
• 481 Does Not Exist: Dialog timeout or NAT interference
• 503 Service Unavailable: SBC overload or maintenance

If 481 occurs, verify network path stability. SIP ALG devices on intermediate routers frequently modify Via headers or drop keepalives, causing the SBC to invalidate the dialog. Disable SIP ALG on all intermediate network devices and configure OPTIONS keepalive at 15s intervals on the Edge trunk.

The Trap: Assuming the Genesys Edge is at fault when the carrier SBC silently drops REFER requests. Carriers often log these drops as Policy Violation without sending a SIP error code, causing the Edge to timeout and return 504 Gateway Timeout to the agent. The architectural reasoning for explicit SBC validation is shared responsibility: REFER success requires mutual agreement on method support, header requirements, and dialog persistence. You must verify carrier policy before modifying Edge configuration.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Referred-To URI Contains Internal Genesys Domain

• The failure condition: Agent initiates blind transfer, Edge returns 404 Not Found to the carrier, call drops with no ringback.
• The root cause: Architect flow uses destinationFormat: EXTENSION instead of SIP_URI. The Edge forwards Referred-To: <sip:ext123@gen-api.genesyscloud.com> to the carrier. The carrier SBC cannot resolve the internal domain and rejects the request.
• The solution: Update the Architect transfer block to destinationFormat: SIP_URI with explicit carrier domain templating. Add a regex validation step before the transfer block to enforce E.164 formatting. Verify the Edge dial plan strips internal domains before outbound routing.

Edge Case 2: 202 Accepted Received but Re-INVITE Never Arrives

• The failure condition: Edge logs show 202 Accepted from carrier, agent hears dial tone then silence, call terminates after 15s with 504 Gateway Timeout.
• The root cause: Carrier SBC accepts the REFER but blocks the re-INVITE due to media path mismatch or codec negotiation failure. The Edge expects the carrier to initiate INVITE with identical SDP attributes, but the SBC modifies the codec list or changes the transport protocol from UDP to TCP.
• The solution: Configure the Edge trunk to enforce RTP/AVP transport and lock codec negotiation to PCMU, PCMA, G729. Enable SDP Fingerprint Verification on the trunk to prevent mid-dialog protocol changes. Add a Wait for Re-INVITE block in Architect with a 20s timeout before routing to fallback.

Edge Case 3: SIP ALG Corrupts REFER Via Headers

• The failure condition: REFER requests succeed in lab environment but fail in production. Edge trace shows Via header IP addresses replaced by NAT public IPs, carrier returns 481 Call/Transaction Does Not Exist.
• The root cause: Intermediate router SIP ALG rewrites Via and Contact headers during REFER transmission. The carrier SBC receives mismatched transaction IDs and invalidates the dialog state.
• The solution: Disable SIP ALG on all edge routers and firewalls. If ALG cannot be disabled, configure the Edge trunk to use SIP NAT Mode: Symmetric and enable Contact Header Rewriting. Force TCP transport for signaling to bypass UDP NAT table fragmentation. Verify OPTIONS keepalive maintains dialog state across NAT boundaries.

Edge Case 4: Carrier Requires P-Asserted-Identity with Specific CNAM Format

• The failure condition: Edge forwards REFER, carrier returns 403 Forbidden, logs show Invalid P-Asserted-Identity format.
• The root cause: Carrier SBC enforces strict CNAM verification on P-Asserted-Identity. The Edge sends sip:agent123@internal.genesyscloud.com but the carrier expects tel:+15559876543 or sip:+15559876543@carrier.example.com.
• The solution: Inject the correct P-Asserted-Identity header in the Architect transfer block using dynamic expression: tel:+1{transfer_to}. Configure the Edge trunk to preserve injected headers across B2BUA boundaries. Validate header format against carrier provisioning documentation.

Official References

• Genesys Cloud Contact Center Edge SIP Trunk Configuration
• Genesys Cloud Architect Transfer Block Reference
• RFC 3515: The Session Initiation Protocol (SIP) REFER Method
• Genesys Cloud Edge SIP Trace & Debugging Guide