RTMP / TCP extra byte in packet?

Question

I'm analyzing the RTMP(Real-Time Messaging Protocol) and found something really weird. In one of the captured packets, the TCP payload length is longer than expected. Here's the packet in Wireshark:

The C3 byte makes the RTMP longer than expected. Which surprisingly gone in the RTMP payload view:

As you can see, the C3 byte disappeared in the RTMP view. But it is part of the TCP payload. I can't get an idea why this happen, I suspect:

1. Some longer UTF-8 character?

   According to wikipedia, the string in AMF0 is encoded into 16-bit UTF-8. It means it can be either 8/16bit. However, \u33C3 and \uC32E are both Korean characters, which shown in the second picture that it isn't my case.

2. Padding / escape character for TCP payload?

   Nah...I never heard about that...

3. Something about TCP that I don't know?

   Here's what I found:

   a. It wasn't a fragment of RTMP message, the TCP packet hold everything a RTMP message need.

   b. The checksum is good, everything seems good.

   c. The packet was correctly ACK-ed by peer (not shown in picture)

   d. This is reproduce-able, by using the streaming software Wirecast

Am I missing something here? Why could Wireshark correctly decode the payload? Why Wireshark simply remove the C3 (that suggests it has nothing to do with AMF0 codec)? I'm so confuse. Please help :'(

RTMP protocol specifications here: https://wwwimages2.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

Answer 1

Oh, I finally figured it out! According to Adobe's document,

The maximum chunk size defaults to 128 bytes

And

5.3.1.2.4. Type 3
Type 3 chunks have no message header...A stream consisting of messages of exactly the same size, stream ID and spacing in time SHOULD use this type for all chunks after a chunk of Type 2.

(Chunk header, also named "chunk basic header", is not message header, they're completely different!)

Here type 3 refers to chunk header type 3, which sits in the first two bits of the first byte with value 0b11xxxxxx. And the reset of six bytes are stream ID (it's 3 here, 0bxx000011). These two statements match the behaviour of my question: new chunk on offset 128 bytes (message header not count) with chunk header type 3. And Wireshark did parse it correctly. A bit confusing: they don't consider chunk header as part of the message, which makes sense. But they did consider the type 0-2 chunk header as part of the message (the first 0x03), which doesn't make sense.

Also, I found a reference here (search C3 and...you get it...): https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol