My Wiresahrk/Tshark tool was not decoding a sip.request correctly , but it was due to the upstream SBC was sending a badly format Request & Method field in the header to begin with. So decoding SIP packets, was reporting some requests as "unknown". In this is case it was a Sip Request OPTIONS.
NOTE: E.g all "Methods" should be uppercase from what I compared to other captured Sip Request
"INVITE" vrs "invite", "BYE" vrs "bye", "CANCEL" vrs "cancel"
And the same for the Request-Line. ( Request-Line: OPTIONS )
Here's a few snapshot of the header and Methods;
( correct )
( incorrect )
The RFC3261 did not give to much details on the character set & with regards to upper & lower case, but this is a summary;
note: In all internet examples, the Request are always shown in UPPERCASE ( INVITE, ACK, BYE, etc... ) In all of my previous trace and pcaps analyzed, this seemed to held true.
So keep that in mind when inspecting SIP datagrams and/or decoding sip datagrams. If wireshark flags these requests as unknown, than a deep inspection of the header should take place.
The SBC in question Sonus 5100 was still replying with a status 200 OK . So a tight inspection of the header format was not taking place or it didn't care about the case-sensitivity. The sending SBC is supposedly a Acme SBC btw.
I checked a few other SIP devices and they are seems to deploy the Requests in upper case. Even my x-lite client sends all requests in uppercase.
I hope this helps others who are scratching there heads, & wondering why the sip request are reported as unknown.
NSE ( network security expert) and Route/Switching Engineer
kfelix --- a----t ---- socpuppets --- dot --- com
=( X X )=