How do I fix invalid characters in decrypted SIP messages?

Hello all,

First of all - thank you to everyone in the forums, it's an extremely helpful tool! Second, I'm somewhat of a newb when it comes to decrypting TLS with wireshark using session keys. I am somewhat familiar with decrypting using private keys (which is what I'm resorting to here). Lastly, I'm probably missing a key bit of information - if that's the case let me know or point me in the right direction and I'll provide it.

I'm capturing packets from an embedded device that's using TLS and has really bad application logging - I can see most information from the application logging but I need to verify that what the application log is telling me is actually being sent across the wire. I have the private key imported into WS I see key exchange, client and server finish key exchange and agree on cipher suite The application uses, or attempts to use LZ77-8K compression

I successfully decrypt 2 SIP messages with the same call ID (a negotiate from client and 200 OK back from server). I see that successfully show in wireshark and it correctly identifies the packet type as "sip"

Every message after that is not identified as sip (and are also unique/new call IDs), and following the SSL stream shows why. Immediately succeeding packets' "Decrypted SSL data" have invalid characters preceding the SIP messages, including:

".....]" "......" ".....~"

removing those characters from the "Decrypted SSL Data" presents a usable SIP message. What I can't figure out is the why, or more specifically, how to determine the "why" - encryption issue, compression issue, or something else. This lasts for 7 SIP messages. Server-side logging (at the application layer) shows normal SIP messages reaching the server, without the additional characters.

After those 7 SIP Messages I have many more that become roughly 90% undecipherable. The decrypted data contains primarily non-alpha ascii characters, however about 10% of the characters are readable and consistent with what would be included in the SIP messages (both SIP headers and XML/content).

I have seen this type of data when using SSL-inspection devices and proxies, however neither are in the mix here. I'm directly spanning the port for the device prior to the packets/frames touching anything else.

Any thoughts from the community on what additional information I can provide to assist in resolving the issue?

Thanks!