So we’ve found this scenario that occurs on some Samsung UEs, in certain radio contions, where midway through an otherwise normal voice call, the UE sends “mystery” data (Not IP data), which in turn causes the UPF to send the error indication and drop the bearer, which in turn drops the call.

The call starts, like any normal call, SIP REGISTER, INVITE, etc.

The P-CSCF / PCRF / PGW set up the dedicated bearer for the voice traffic, and the RTP stream starts flowing over it.

Then the UE sends these weird packets instead of the RTP stream:

These are GTP-U encapsulated data, with the TEID that matches the TEID used for the RTP stream, but there’s no IP data in them – they’re only 14 bytes long and sent by the UE.

Here’s some examples of what’s sent (each line is a packet):

d097ab7d605665f4f8f7cf7805c0
...
d198c445614c64f4f8f7cf7805c0
...
d298fd4d624263f4f8f7cf7805c0
...
d398be55633862f4f8f7cf7805c0
...
d498f45d642e61f4f8f7cf7805c0

Per 3GPP you can’t transmit anything other than IPv4 or IPv6 unless you’re using NIDD, but this is not using NIDD or Ethernet.

An IPv4 header is 20 bytes long, and IPv6 header is 40, so this is too short for either of those protocols, but what else could it be?

There’s some commonality of course, starts d0 as the first octet, then d1, d2, d3, etc. So that’s something?

I thought perhaps it was a boundary issue, that the standard RTP packet was being split across multiple GTP-U payloads, but that doesn’t appear to be the case.

An Ethernet header is 14 bytes, but if we were to decode this as Ethernet there’s still nothing it’s transporting, and the destination MAC is changing sequentailly if that’s the case, which would be even weirder.

I also thought about RTP that for some reason has lost it’s IP/UDP header, as the sequentially counting byte at the start could be the RTP sequence number, but that’d be 19 bytes minimum and the sequence number is the 3rd and 4th byte, not the first.

Whatever they contain, we see this sent over and over for a few seconds, then bam, back to normal RTP stream flowing.

Or at least it should be, but the invalid packet causes the UPF to generate a GTP-U Error Indication.

These Error Indication payloads eventually lead to the next PFCP Session Report Request having the Error Indication Report (ERIR) flag set to True.

When the PGW-U gets this, it sends a Session Delete Request, which dutifully drops the bearer.

Meaning the session drops on the EPC side, and the RTP drops with it, eventually a BYE is sent from the phone due to RTP timeout.

The above screenshot shows a different cause of GTP-U Error Indication – At this point the bearer has been dropped on the EPC side and these are Error Indications to report it doesn’t know the TIED / bearer.

How to fix this?

Well, unlikely we’ll get a fix on the Samsung side, so we’ll need to not drop the bearer on the PGW-C if we get a lot of Error Indications, and hope for the best.