I’ve noticed what seems to be a serious RTP leak issue in Yeti-Switch.
Here is one way to reproduce it:
Start a call between leg A and leg B.
During the conversation, block the SIP port of the caller (leg A).
Hang up the call from leg B.
What happens:
On leg B the call is terminated as expected.
On leg A the call is still shown as active/in conversation, because SIP signaling cannot reach it.
If leg A remains connected long enough, it eventually starts receiving RTP audio from other unrelated calls, as if their RTP streams were attached to the same session.
Unfortunately this cannot be reproduced via SIP trace or TCP dump, because from Yeti’s point of view the call is already closed. Yeti sees the BYE as sent on both sides, closes the transaction, bills the call, and truncates the log at that point.
This looks like a serious security and privacy issue, since a user on leg A can overhear audio from other calls.
Questions:
Is this a known problem?
How can it be solved or mitigated?
Shouldn’t Yeti-Switch forcefully tear down the RTP session once one leg has terminated, regardless of the signaling state on the other side?
I’m making tests with node version 1.12.46core102, no proxy involved because I tested directly on SEMS node
Thanks in advance, this seems like something that needs urgent attention. Please let me know
The graph only shows the INVITE and RTP, but when LEG B close the call the two RTP channels are not removed and yeti seems it’s not processing the BYE from LEG B trying to forward to LEG A.
They remain active/connected on both sides.
The next call that reuses the same channel can then be overheard by leg A, since the RTP streams remain the same.
Final Bye from LEG A is because LEG A closed the call. (firewall blocked only outbound connection to LEG A)
Your interpretation of root cause of this effect is wrong, but this is well-known behavior of symmetric rtp mechanism. You can disable it in gateway settings.
Also you have to provide pcap in such cases because images are useless.
Just to explain my point of view: since symmetric RTP is enabled by default, I honestly didn’t even know what it was doing internally,I simply left it as it was. The problem I described is something that my clients actually experienced in production, not just in a lab test.
From their perspective, the issue manifests exactly when there is a loss of SIP signaling: one leg still thinks the call is active and continues to receive audio, which in some cases ends up being media from other call with all the privacy related Issues.
So disabling this feature it will fix this issue? Do I need to disable it on both sides? Origination and termination? thanks
