The NetSapiens inter-domain calling quirk that keeps showing up

Quick share. Been running into this enough times across NetSapiens deployments that it's worth flagging.

Scenario: Call gets placed or transferred between two domains on the same NetSapiens platform. The call connects fine. Audio works. But the caller ID showing up on the receiving side is wrong. It's showing the local extension or domain user instead of the actual originating caller.

If you check the NetSapiens Known Issues page, this maps to NMS-2518. It shows up specifically when calls cross domain boundaries during hold or transfer.

The fallout is mostly cosmetic but it matters for anyone running multi-tenant reseller deployments. Your customer sees the wrong name in their call history. Voicemail attribution gets weird. Inter-domain analytics show calls from the wrong source.

A few patterns I've seen work around it:

• Configure SIP header rewriting at the SBC layer to preserve the original From URI across domain hops
• For softphones that pull call history from NetSapiens API directly, verify which field the client is actually displaying. Some pull from orig_user, others from local_user. The discrepancy shows up clearer than you'd expect.
• If you're running a mobile softphone client, check whether the client is caching contact info locally and overriding what NetSapiens returns. A lot of "wrong caller ID" reports turn out to be client-side caching bugs, not platform bugs.

The deeper fix is platform-side and depends on what NetSapiens version you're running. The cleaner softphone integrations route call history through the NetSapiens API rather than building it locally on the device, which sidesteps the worst of this behavior.

White-label softphones that integrate natively with NetSapiens handle this more consistently than generic SIP clients. Tragofone is one example where the call history syncs through the NetSapiens softphone integration layer directly, so inter-domain caller ID is consistent with what the platform actually has. Other native integrations handle this similarly. Generic SIP clients that just register against NetSapiens without API integration tend to get hit by this more often.

Anyone else seeing this on their deployments? Curious if there's a version of NetSapiens where this got cleaner that I'm missing.