Describe the transfer mechanism
Record whether the user attempted a blind or attended transfer, which phone initiated it and where the destination is located. A phone-generated REFER and a PBX feature-code transfer may use different call-control mechanisms. Verify the actual signaling before diagnosing a REFER failure.
Keep one working transfer to a known internal destination as a comparison if possible. Note whether the original caller stays connected, hears hold music or is disconnected.
Illustrative REFER event workflow. NOTIFY can arrive before the REFER response; actual order and call legs vary.
Separate acceptance from completion
For the usual REFER event workflow, a successful response accepts the request; NOTIFY messages report progress and the final result through a sipfrag body. Read the REFER response, the new destination call attempt and the matching notifications. Do not treat an accepted request as proof the destination answered.
Correlate the relevant dialog and Event information. The PBX can create a separate Call-ID on the referred call leg, so searching only the original Call-ID can hide the failure.
Investigate the failing branch
If REFER is rejected, check the exact endpoint’s transfer permissions and destination policy. Asterisk documents allow_transfer for SIP REFER permission. If REFER is accepted but no destination call is attempted, inspect target interpretation and PBX routing.
If the new INVITE is rejected, diagnose that response on the new leg. If the destination answers but the original caller cannot hear it, follow the media bridge and negotiated stream after transfer. These findings lead to different corrections.
Keep attended transfer evidence intact
For attended transfer, record the consultation call as well as the original call. Preserve the target dialog references when sharing a redacted trace with authorized support; removing all identifiers can make the relationship impossible to follow. Test that the consulted party is the one actually joined.
After the correction, verify blind transfer, attended transfer, busy destination and no answer under the organization’s chosen behavior. Confirm what happens to the original caller in each case. Keep a usable return-to-caller procedure in staff instructions.
Watch the explanation
Covers the T54W controls and everyday calling tasks, including attended versus blind transfer, conference management, Wi-Fi and Bluetooth. Useful for onboarding phone users.
Read applicability and editorial notes →Watch this video here
T54W demonstration on UD Voice in 2022. The video title and narration identify T54W; its description contains copied references to other models. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
See how a preconfigured busy-lamp-field key can hand off an active call in one press. The short example is useful for reception staff who already have named extension keys and want to understand what happens when they select a colleague during a call.
Read applicability and editorial notes →Watch this video here
Accelerate Networks GRP2615 key configuration. BLF subscriptions, transfer mode and lamp behavior depend on the phone template and PBX. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.