SIP.
In SIP, a request and its response, or responses, constitute a transaction.
A request can have several provisional responses and one final response.
All transactions belonging to the same session constitute a dialog.
A dialog represents a peer-to-peer SIP relationship between two User Agents that
persists for some timee.
The dialog can be identified by the Call-ID together with the tags in the “To” and
“From” header fields of the message.
A dialog can also be referred to as a call leg.
***********************************************************************************
*****************************************
Sip header / Message
To: Indicates the destination for the SIP message.
From: Indicates the origin of the SIP message (UAC).
The To and From fields may include a tag. The tags together with the Call-Id
identify the call leg.
Max-Forwards - is the maximum number of SIP hops allowed.
Cseq - is a sequence number, incremented for every new transaction. It is used for
matching responses to the right request.
Content- Type indicates the type of content in the Message Body, for example SDP.
Content-Length- is the size of the included content in octets.
RSeq and RAck - are used with provisional responses and PRACKs.
Reason - is used to indicate the reason for session termination by CANCEL or BYE
messages
Expires, Min-Expires, Session-Expires and Min-SE - are used to control re-
registrations and periodic refresh of SIP sessions.
They specify Expiration times and minimum values that those can be changed to.
PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured
hop-by-hop through each stateful proxy.
Also like BYE, but unlike ACK, PRACK has its own response. ...
The PRACK messages contain an RAck header field, which indicates the sequence
number of the provisional response that is being acknowledged.
***********************************************************************************
****************************************
The P-headers are SIP headers used specifically for IMS.
They include:
P-Asserted-Identity,--
identifying the sending user. It is inserted by a trusted entity in the network.
If present in a SIP INVITE, this Id is used by S-CSCF to examine a user’s
originating triggers, overruling the ‘From’ header.
P-Visited-Network-ID, ---
an identifier of the visited network, inserted by the P-CSCF in that network.
Used by the home network to validate the existence of a roaming agreement.
P-Access-Network-Info, or PANI,--
indicates the type of access technology used, and in the case of cell and mobile
access,
optionally the ID of the cell where the terminal is connected. The PANI header is,
among other things, used to enable Access Awareness in the CSCF.
***********************************************************************************
************************************************************
SIP REQUEST-----
SIP is based on an HTTP-like request/response transaction model.
Each transaction consists of a request that invokes a particular ‘Method’, or
function, on the server, and results in at least one response.
REGISTER -- is used to create a binding between the SIP address and the current
contact address of a user.
Its purpose has been extended for IMS to also include Authentication of the User.
INVITE -- establishes a dialog and is typically used to request a session with
another User Agent.
The INVITE will in most cases include an attached SDP offer.
ACK is a final acknowledgement that terminates an INVITE transaction
CANCEL can be used by the UAC to terminate a transaction before the final response
has been received. After a final response has been generated,
the CANCEL will have no meaning.
BYE ends a session, and triggers a release in the user plane.
OPTIONS allows a UA to query another UA or a proxy server as to its capabilities.
This allows a client to discover information about the supported methods, content
types, extensions, codecs, and so on, without "ringing" the other party
UPDATE is an extension to the SIP protocol that allows for updating a session
during session establishment, without affecting the state of the SIP dialog
PUBLISH is used to publish “Event State” information to a server
SUBSCRIBE is used to request presence information updates about a user from a
Presence Server.
NOTIFY is used by a Presence Server to send presence information about a user to
other users.
MESSAGE is used to transfer an instant message between users.
INFO is used for transporting application level information via the SIP signaling
path without changing the state of the session or the SIP dialog.
REFER indicates that the recipient should contact a third party, using the ‘refer-
to’ information provided in the request.
Refer can be used to enable many applications, including Call Transfer and 3-way
calls
transaction
A transaction is a sequence of SIP messages exchanged between SIP network elements.
A transaction consists of one request and all responses to that request.
***********************************************************************************
****************************************************************
100 Trying
Means that the request has been received by the next-hop server and action is being
taken on behalf of the call.
180 Ringing
Indicates that the user equipment is alerting the user.
183 Session Progress
Is used to convey information about the progress of the call.
200 OK
Means that the request has succeeded.
302 Moved Temporarily
Indicates that the requesting client should retry the request at a new address,
given by the Contact header field.
401 Unauthorized
Means that the request requires user authentication.
500 Server Internal Error
Means that the server encountered an unexpected condition that prevented it from
fulfilling the request.
606 Not Acceptable
Means that the user agent was contacted successfully but that some aspects of the
session description, such as the requested media, bandwidth, or addressing style
weren’t acceptable.
***********************************************************************************
************************************************************************
SIP Routing Summary
Request URI
The Request URI indicates the destination of a SIP message.
This can be a user or a service. It is used in combination with DNS lookup,
normally for the first request in a dialog. The Request URI is overruled by the
Route header.
Record-Route
The Record-Route header field is inserted by a proxy to force future SIP requests
within the on going session to be routed through the proxy.
Route
The Route header field is used to route requests through a listed set of proxies.
Via
The Via header field indicates the path that should be followed in routing
responses.
A proxy inserts its own address in a Via header before proxying a request.
Contact
The Contact header field tells the terminating proxy where to send future requests.
The Contact header is cached and inserted in the Request-URI header when new SIP
Requests are initiated.
***********************************************************************************
**************************************************************
The SDP protocol consists of the types
V for version, is currently always 0.
O for origin, contains user name and address, among other things.
S for session name, which is normally just a dash.
C for connection information, used for the media, identifies the IP address where
media should be received, the address type and the network type.
T for time is mandatory, but is not used in IMS. Therefore, t=0 0 is always set.
M for media, specifies the media type, for example audio, video or application,
which port and transport type to use, and a list of payload formats further
described in the A–types.
A for attributes can be “session level”, “media level” or both. Session level
attributes apply to the whole session, and are used for controlling the media
direction, whereas Media attributes apply to a specific media, for example
specifying codec information.
invite message ex:-
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:4687131009@[Link] SIP/2.0
Message Header
Via: SIP/2.0/UDP [Link]:5060;branch=z9hG4bK-d8754z-cb68f880ab1e97d5-1---
d8754z-;rport
Max-Forwards: 70
Route: <sip:[Link]:5060;transport=udp;lr>
Contact: <sip:4687131010@[Link]:5060>
To: <sip:4687131009@[Link]>
From: "User 10"<sip:4687131010@[Link]>;tag=96089bac
Call-ID: MmM4YjdiYWI4YWU2OTI4MzNiMWQ2YjFjNGYzNzU4MWM.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: X-Lite release 5.0.0 stamp 67284
Content-Length: 244
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 13007554861509227 1 IN IP4 [Link]
Session Name (s): CounterPath X-Lite 5.0.0
Connection Information (c): IN IP4 [Link]
Bandwidth Information (b): AS:1638
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 5062 RTP/AVP 107 0 8 101
Media Attribute (a): rtpmap:107 BV32/16000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv
***********************************************************************************
******************************************************************
SIP Server types:-
Proxies are classified as stateless or stateful depending on whether they keep
track of session variables or not.
Some proxies remain in the signaling path for the full duration of the session
while others drop out after the first transaction.
In IMS, the S-, P- and E-CSCFs are stateful proxies,
while the I-CSCF is stateless.
Back-to-Back User
a Back-to-Back User Agent consists of two user agents. Signaling for a call enters
one of the UAs, acting as a UAS, and leaves through the other UA, acting as a UAC.
The difference compared to a proxy is that the B2BUA can modify the payload, for
example the SDP. When a Back-to-Back user agent is used, the connection will
consist of two call legs, one on each side of the server.
In IMS, the Application Servers, SBGs and MGCs act as Back-to-Back User Agents.
SIP Redirect
server does not act as a proxy. Instead, it g formation about where to send a
session establishment request back to a client, which then re-sends the request
towards the correct destination. The Redirect server is not implemented in IMS.