What is SIP?
The Session Initiation Protocol (SIP) is a signaling protocol used for
initiating, maintaining, and terminating communication sessions that include
voice, video, presence, instant messaging, and among other applications. SIP is
used in Internet telephony, in private IP telephone systems, as well as mobile
phone calling over LTE (VoLTE).
What is the format of SIP?
RFC 3261 7.0 SIP Messages
SIP is a text-based protocol and uses the UTF-8 charset.
There are 4 parts of a SIP packet. The first three parts are required.
1) the start line (one line)
2) header (multiple lines)
3) blank CRLF line .
4) The message body is optional.
In order, here are the parts of a generic SIP message structure:
Start-line [ AKA Method line or Status line ]
SIP header [ Multi-line header with session information ]
Blank line consisting of just a CRLF [ In C language \r\n ]
Body [ Message-body ]
The start-line, each message-header line, and the empty line MUST be
terminated by a carriage-return line-feed sequence represented as (CRLF) or [\r\n].
Note that the empty line MUST be present even if the message-body is not.
Example #1 [SIP INVITE with no message body]:
INVITE sip:52222@10.0.0.2 SIP/2.0 <- Start line / Method line -
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK776asdhds <- Start of SIP header -
Max-Forwards: 70 - -
To: "Bob" <sip:52222@10.0.0.2> - -
From: "Alice" <sip:+51111@10.0.0.2>;tag=1 - -
Call-ID: a84b4c76e66710 - -
CSeq: 1 INVITE - -
Contact: "Alice" <sip:+51111@192.168.10.10:5060> - -
Diversion: "Sales" <sip:+50000@10.0.0.2> - -
P-Asserted-Identity: "Alice" <sip:+51111@10.0.0.2> - -
Content-Length: 0 <- End of SIP header -
<- CRLF empty line -
Example #2 [SIP INVITE with SDP for body]:
INVITE sip:001234567890@10.135.0.1:5060;user=phone SIP/2.0 <- Start line / Method line -
Via: SIP/2.0/UDP 10.135.0.12:5060;branch=z9hG4bKhye0bem20x.nx8h <- Start of header -
Max-Forwards: 70 - -
From: "Timmy Bowers" <sip:151@10.135.0.1:5060>;tag=m3l2hbp - -
To: <sip:001234567890@10.135.0.1:5060;user=phone> - -
Call-ID: ud04chatv9q@10.135.0.1 - -
CSeq: 10691 INVITE - -
Contact: <sip:151@10.135.0.12;line=12071> - -
Allow: INVITE, CANCEL, BYE, ACK, REGISTER, SUBSCRIBE, NOTIFY, INFO, UPDATE - -
Content-Disposition: session - -
Supported: replaces,100rel - -
User-Agent: VoipOneAIR 03.55.00.24 9c7514340722 02:76:f3:d6:64 - -
Content-Type: application/sdp - -
Content-Length: 254 <- End of SIP header -
<- CRLF empty line -
v=0 <- Start of body (message) -
o=151 9655 9655 IN IP4 10.135.0.12 - -
s=- - -
c=IN IP4 10.135.0.12 - -
t=0 0 - -
m=audio 50024 RTP/AVP 8 0 2 18 - -
a=rtpmap:8 PCMA/8000 - -
a=rtpmap:0 PCMU/8000 - -
a=rtpmap:2 G726-32/8000/1 - -
a=rtpmap:18 G729/8000 - -
a=ptime:20 - -
a=maxptime:80 - -
a=sendrecv - -
a=rtcp:50025 <- End of body (message) -
RFC 3261 7.1 Requests
SIP requests are distinguished by having a Request-Line for a start-line. A
Request-Line contains a method name, a Request-URI, and the protocol version
separated by a single space (SP) character.
Example:
PUBLISH sip:51234@10.0.0.27 SIP/2.0
The Request-Line ends with CRLF. No CR or LF are allowed except in the
end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the
elements.
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method: This specification defines six methods:
REGISTER for registering contact information,
INVITE,
ACK,
CANCEL for setting up sessions,
BYE for terminating sessions, and
OPTIONS for querying servers about their capabilities.
SIP extensions, documented in standards track RFCs, may define
additional methods. For example SIMPLE for IM and presence.
SIMPLE = SIP Instant Messaging and Presence Leveraging Extensions
SIMPLE expands to additional Methods like:
MESSAGE
SUBSCRIBE
NOTIFY
PUBLISH
Request-URI indicates the user or service to which this request is being addressed.
The Request-URI MUST NOT contain unescaped spaces or control characters and
MUST NOT be enclosed in "<>".
SIP elements MAY support Request-URIs with schemes other than "sip" and "sips",
for example the "tel" URI scheme. SIP elements MAY translate non-SIP URIs using
any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other
scheme.
RFC 3261 7.3.1
Headers needed by a proxy should be on top
RFC 3261 8.1.1
Mandatory SIP headers
- - "Via:" header field must be populated
- - "To:" header field must be populated
- - "From:" header field must be populated
- - "CSeq:" header field must be populated
- - "Call-ID:" header field must be populated
RFC 3261 18.2.1
When the server transport receives a request over any transport, it
MUST examine the value of the "sent-by" parameter in the top Via
header field value. If the host portion of the "sent-by" parameter
contains a domain name, or if it contains an IP address that differs
from the packet source address, the server MUST add a "received"
parameter to that Via header field value. This parameter MUST
contain the source address from which the packet was received.
RFC 3261 18.4
The Content-Length header field MUST be used with stream oriented transports i.e. TCP.
RFC 3261 20.14
If no body is present then Content-Length MUST be 0
RFC 3261 20.15
Content-Type MUST be present if body is not empty
Com
SIP
L