A SIP Request Header gotchas

Debugging some sip stuff this last few weeks,  I ran into something that  was a little strange & that I would like to share with you.

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;

http://tools.ietf.org/html/rfc3261#section-7.1

but RFC2543

https://www.ietf.org/rfc/rfc2543.txt

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.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  --- a----t ---- socpuppets --- dot --- com

     ^      ^
=(  X   X )=
         o 
        /  \