Monday, September 29, 2014

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;

but RFC2543

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 )=
        /  \

No comments:

Post a Comment