# Yesterday, REFERs stopped matching on outbound
**URL:** https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190
**Category:** Telephony
**Tags:** sip-other-provider
**Created:** [May 20, 2026, 8:56pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190 "2026-05-20T20:56:26Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Mark\_Diaz](https://community.livekit.io/u/Mark_Diaz)
#### Post date: [May 20, 2026, 8:56pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/1 "2026-05-20T20:56:26Z")
Timeline: Transfers/REFERs were working fine until yesterdat approx 5pm EST.
SIP`transfer_sip_participant`suddenly failing with 407 Proxy Authentication Required. From-URI realm mismatch. Seems SIP livekit backend is now passing the wrong SIP domain in the from host..
---
### Author:  [@Muhammad\_Usman\_Bashir](https://community.livekit.io/u/Muhammad_Usman_Bashir)
#### Post date: [May 20, 2026, 10:57pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/2 "2026-05-20T22:57:28Z")
@Mark_Diaz, For a Cloud-side LK SIP backend regression on outbound `REFER`, support is the right channel. Backend logs for your project ID will tell the team whether the From URI construction shifted.
`livekit/sip` has had commits in the past two weeks touching SDP behavior, inbound auth realm customization, and `407` state handling, but `none of them explicitly describe a REFER From URI change`. Mentioning the timing window on your support ticket gives the team something to correlate against.
Transfer API reference: [Call forwarding | LiveKit Documentation](https://docs.livekit.io/sip/transfer-cold)
---
### Author:  [@CWilson](https://community.livekit.io/u/CWilson)
#### Post date: [May 21, 2026, 5:07pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/3 "2026-05-21T17:07:20Z")
Do you have a call id that failed?
---
### Author:  [@Mark\_Diaz](https://community.livekit.io/u/Mark_Diaz)
#### Post date: [May 21, 2026, 8:19pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/4 "2026-05-21T20:19:26Z")
Last test: ‘SCL\_q4mhpfYxC7y4’
It was working fine until Monday approx 5pm EST. SIP engineering team tells me the LK sip gateway from\_host is no longer matching the realm, as it was previously.
---
### Author:  [@CWilson](https://community.livekit.io/u/CWilson)
#### Post date: [May 26, 2026, 12:11pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/5 "2026-05-26T12:11:22Z")
> [@Mark\_Diaz](#):
>
> SIP engineering team tells me the LK sip gateway from\_host is no longer matching the realm, as it was previously.
Looked at the code and the LiveKit‑side REFER From URI behavior has not changed in ~8 months. The change that aligns with the your timeline must be on the SIP provider’s side.
Do you have a call ID that previously worked? It is not exactly clear to me why you would expect your SIP provider to even have credentials for `5sii....sip.livekit.cloud` since that is LiveKit domain.
---
### Author:  [@Mark\_Diaz](https://community.livekit.io/u/Mark_Diaz)
#### Post date: [May 26, 2026, 1:11pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/6 "2026-05-26T13:11:39Z")
I agree. I also looked at the code but I was not sure if your repo was in sync with what you’re running on your cloud.
**SCL\_rYdAiTBCm67q**
---
### Author:  [@CWilson](https://community.livekit.io/u/CWilson)
#### Post date: [May 26, 2026, 4:59pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/7 "2026-05-26T16:59:18Z")
So I looked at the PCAP for that **SCL\_rYdAiTBCm67q** (success) and **SCL\_q4mhpfYxC7y4** (fail) and the `REFER` are nearly exactly the same. So not sure why your team believes its an issue on the LiveKit side.
Just to be sure I took a look at all the SIP changes between the two calls:
```auto
livekit/sip: bfbe8eb per-call media timeout
dba15f9 configurable TLS ALPN
36d7d59 track log consolidation
be9e564 CANCEL race
bab77e1 SDP local-IP / symmetric mode
549c718 Allow customizing auth realm for INBOUND calls
d3e37ef media timeout correctness
cb9c0b4 disable TURN for LK RTC
```
None of these touch the outbound REFER From-URI path.
**What the PCAPs also show** : the FreeSWITCH node that handled the May 14 REFER was `157.xxx.xxx.28:11000`; the one that 407’d on May 21 was `157.xxx.xxx.27:11000`. Different Kazoo nodes, same trunk.
I would check if that’s consistent with SIP proxy rolling out a config or upgrade to part of their FreeSWITCH cluster (e.g., a new ACL/auth profile on `:.27`) between your two tests, while `:.28` was either upgraded later or carries a different policy.
Why is the proxy challenging an in-dialog REFER?
---
### Author:  [@Muhammad\_Usman\_Bashir](https://community.livekit.io/u/Muhammad_Usman_Bashir)
#### Post date: [May 26, 2026, 8:00pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/8 "2026-05-26T20:00:00Z")
@Mark_Diaz, The PCAP comparison settles it: `near-identical` REFERs from the LK side on both calls, the only material difference being which Kazoo node handled them (`157.x.x.28 accepted May 14`, `157.x.x.27 407'd May 21`). That rules out the LK-side From URI theory.
The practical next step is with your SIP provider. Take **both node IPs** to whoever operates that `FreeSWITCH/Kazoo` cluster and ask why `.27 rejects` the From URI realm that `.28 accepts`. The common cause is per-node `auth/realm` config drift: one node picked up a config change around your May 21 timeline that altered how it validates the From host, while the other kept the prior behavior. Same trunk, divergent node config.
They can confirm by diffing the SIP profile and realm ACL between the two nodes. That diff is where the `407` is coming from.
---
### Author:  [@Mark\_Diaz](https://community.livekit.io/u/Mark_Diaz)
#### Post date: [May 26, 2026, 8:14pm UTC](https://community.livekit.io/t/yesterday-refers-stopped-matching-on-outbound/1190/9 "2026-05-26T20:14:51Z")
As I am the SIP carrier 🙂 I will push my engineering team to investigate. I greatly appreciate the diligence, clarification and SIP traces. I’ll update soon! Thank you team!