IMS SMS and Wireshark

Objects in (the) Wireshark are not same as they appear

It is usual in the software teams, without regular code review sessions, that someone leaves the group and, over time that other services are ready to test, something doesn’t work after deployment.

This scenario happened to me last week, when I deployed IMS SMS services in a lab environment and everything was ready for the test with a real mobile handset, I noticed something is not correct.

But what was the issue? When UE A after registration to VoLTE, sent an SMS to UE B, just the first message has delivered without issue, and later messages were not sent. Sometimes two messages were sent, and others were not.

I check the service Lambdas’ logs and found some SIP 400 response messages from sender UE. In these cases, the best option for troubleshooting is network capturing and checking in Wireshark to see what exactly going on. If you have reference captures (from other production networks), you would be lucky because you can check with reference capture.

In the capture everything was good, I checked all the MESSAGE requests and 202 Accepted responses and all headers were correct.

And the second SMS, made this error, when we sent delivery report (RP-ACK) to the sender:

Method mismatch btw Request Line and CSeq didn’t have any meaning to me. Method and CSeq were the same. I checked again other headers in the delivery report SIP Message and they looked good.

Ok, so I started to review the function codes, especially the function that made the delivery report. Ah! I found it. Someone was concatenating the RP-ACK payload buffer as a body to the SIP Message string!! Something like this:

1
2
3
4
5
6

const deliveryReportBuff = Buffer.from(deliveryReport, "hex");

...
  response += `Content-Length: ${deliveryReportBuff.length}\r\n`;
  response += "\r\n";
  response += deliveryReportBuff;

Obviously, it won’t work! or it won’t properly for all messages. But what caused which I to spend more time finding the issue? Wireshark! Wireshark could show the RP-ACK payload and without checking the hex string of the SIP body and checking the body length, it wasn’t easy to see the problem. So I create a buffer from message string and concatinating with payload. So now the length and content of message is correct and SMS over IP works well!

Conclusion: If you see that Wireshark can parse the packets, it doesn’t mean that your packets have been created correctly. You need to check the Hex string and be sure about the exact content.