ISUP multipart encoding issue

[mkpaz]

I send HEP packets that contains a SIP message with ISUP attachment like this:

436f6e74656e742d446973706f736974696f6e3a207369676e616c3b68616e646c696e673d72657175697265640d0a0d0a << boundary
011048000a03020a0804108764125250f53904c0d03dc00a0884138764020090093d011bc00906841387640200900900 << ISUP binary
0d0a2d2d7369702d626f756e646172792d4d7a316753574e5756542d2d << boundary

I compared it with the actual SIP message and they're identical and can be decoded by Wireshark dissector.

But after inserting into PgSQL database it looks like this:

436f6e74656e742d446973706f736974696f6e3a207369676e616c3b68616e646c696e673d72657175697265640d0a0d0a << boundary
0110480a03020a0804106412525039043d0a08136402093d011b090613640209 << ISUP binary
0d0a2d2d7369702d626f756e646172792d4d7a316753574e5756542d2d << boundary

Some bytes just lost in the process:

011048000a03020a0804108764125250f53904c0d03dc00a0884138764020090093d011bc00906841387640200900900 << hep
0110480  a03020a080410  64125250  3904    3d  0a08  13  64020    93d011b 090 6  13  64020 9 << database

So, tshark decoder fails with some JSON error.

I suppose it's some encoding problem. Here is a similar issue, except Heplify removes more than just \x00.

[lmangani]

@mkpaz thanks for raising this can you provide a pcap to reproduce this end-to-end?

[mkpaz]

@lmangani Thanks for the response. Yes, I've attached all info including pcap for both SIP and HEP side.

isup_encoding_issue.zip

[mkpaz]

@lmangani Any suggestions would be greatly appreciated. I've tried to compile a look at it myself, but I'm not a Go coder.

[lmangani]

Thanks for your patience @mkpaz! Busy times. @adubovikov will review and patch if needed, once time allows