Sip Concept



RFC summary

Hitchhiker's Guide to SIP

classified by IETF working group.

working groups

The following working groups at the IETF work on SIP directly and indirectly:

  • SIP – The original SIP group. Now deals with extensions to the standard.
  • SIPPING – Session Initiation ProPosal INvestiGation. This group is responsible for examining new requirements for the SIP protocol and deciding if an extension to the protocol is required.
  • SIMPLE – SIP for Instant Messaging and Presence Leveraging Extensions. This group is responsible for the IM and presence extensions for SIP.
  • XCON – Centralized CONferencing. This group is responsible for creating a set of protocols for tightly coupled multimedia conferences. Not all the protocols of this group will be SIP, but some (if not most) of them will be.

jungle of multi party RFC

sip-i vs sip-t

overview of sip

Diagrams :
SIP: understanding the Session Initiation Protocol By Alan B. Johnston

sip refresher

service concept

SIP trunk

sip core cencepts

strict routing vs loose routing.


In a SIP based IP telephony calls, DTMF signals may be carried as (1) embedded audio, in which case the low bandwidth codecs distort the signal, causing problems in recognization at the receiving end, (2) special RTP packet as per RFC 2833 and signalled as telephone-event media type, or (3) SIP INFO request containing message body describing the signal. The option (2) is preferred, since it avoids the signaling path.


sip headers are cases -insensitive (sip requests are case sensitive)

  • allow : supported methods
  • supported: indicated supported feature capabilities by UAC/UAS. normally it is in response to OPTIONS request.
  • allow-events: indicates the events packages it supports
  • accept : media types.


fmtp: format parameters of transport.


DNS provides two record types relevant to SIP requests: SRV and NAPTR. Some implementations will use SRV records only.

- NAPTR records provide a mechanism for the called domain to specify which protocols it prefers a SIP request to use.
SIP+D2U for SIP over UDP
SIP+D2T for SIP over TCP
SIP+D2S for SIP over SCTP

SIPS+D2T for secure SIP over TLS over TCP. (TLS over UDP is not defined. )

- SRV records: for determining the SIP host address, port of the host to which a SIP request is sent.

stateful vs stateless

early media
early media



- no secure
- authenticated: only message authentication is enabled for SIP in TLS, no encryption of SIP.
- encrypted: SIP in TLS has both message authentication and encryption. RTP is both authenticated(header fields + payload) and encrypted(payload only) : sRTP

- default authentication: HMAC-SHA1
- default cipher for encryption is AES in 128 bits encryption key.

symmetric keying is normally used for encryption algorithms, such as AES, as well as authentication transforms, such as HMAC-SHA1. the actual process for exchanging
of keying material for sRTP has two approaches:

  • in SDP of signal flow. RFC 4568
  • datagram TLS (dTLS) in media flow RFC 4347



A UA must maintain the state on calls that it initiates or participates in. A minimum call state set includes the local and remote tags, Call-ID, local and
remote CSeqheader fi elds, along with the route set and any state information necessary for the media. This information is used to store the dialog information
and for reliability. Even after a call has been terminated, the call state must be maintained by a user agent for at least 32 seconds in case of lost
messages in the call tear down.

The remote CSeq storage is necessary to distinguish between a new request and a retransmission of an old request.

  • A re-INVITE is used to change the session parameters of an existing or pending call. It uses the same Call-ID and tagsas the original INVITE/200 OKexchange, but the CSeq is incremented because it is a new request.
  • A retransmitted INVITE will contain the same Call-ID and CSeq as a previous INVITE.

The CSeq number is never
incremented for an ACK, but the CSeq method is changed to ACK. This is so that a UAS can match the CSeqnumber of the ACKwith the number of the correspond-ing INVITE.


CANCEL is a hop-by-hop request and receives a response generated by the next stateful element.

The CSeq is not incremented for this method so that proxies and user agents can match the CSeq of the CANCEL with the CSeq of the pending INVITE to
which it corresponds.

The branchID for a CANCEL matches the INVITE that it is canceling. A CANCEL only has meaning for an INVITE since only an INVITE may take several
seconds (or minutes) to complete. All other SIP requests complete immediately (that is, a UAS must immediately generate a fi nal response). Consequently, the
fi nal result will always be generated before the CANCEL is received.

branch id

The branch parameter is a transaction identifi er. Responses relating to this request can be correlated because they will contain this same transaction identifier.

A response matches a client transaction under two

1. If the response has the same value of the branch parameter in
the top Via header field as the branch parameter in the top
Via header field of the request that created the transaction.

2. If the method parameter in the CSeq header field matches the
method of the request that created the transaction. The
method is needed since a CANCEL request constitutes a
different transaction, but shares the same value of the branch


Reliability mechanisms in SIP include:
- Retransmission timers;
- Increasing command sequence CSeq numbers;
- Positive acknowledgments.



strict vs loose routing

SIP Security TLS & sRTP


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License