SIP is powerful precisely because it can be used to establish any kind
of session. Voice sessions are just one example.
SIP UA : interface for the users e.g IP phones, computer applications to make call
Redirect Servers: help locate SIP UA; it simply returns the list of the possible SIP UA addresses e.g BOB@university.com BOB@company.com
Proxy Servers: reduces the overload of the information and acknowledgment (look page 104 Sip Demystified)
Registrar/SIP server: It refers to both: Redirect and Proxy Servers
Location Servers: Most registrars upload location updates to a location
server upon receipt. SIP is not used between location servers and SIP servers. It uses LDAP to communicate with SIP servers
SIP clearly distinguishes between session establishment and session description. SIP
just provides connectivity; what users do with it is outside of the scope of
SIP.
SIP does not even assume that the session it has established will take place in the
Internet. For instance, if Bob wants to invite Laura to join a conference call
that is taking place in the public-switched telephone network (PSTN), all he
has to do is use SIP to deliver the telephone number that she can dial to join
in. In this example, the session description would contain a telephone number
instead of IP addresses and UDP ports. When SIP delivers the session
description to Laura, she reacts as she does to any kind of ping with the tool
she’s been given.
SIP provides just enough information for the invitee to accept the invitation
Servers that do notneed to monitor signalling for the duration of the session can handle a larger number of sessions.
when two user agents exchange SIP messages, the User Agent (UA) sending
requests is the User Agent Client (UAC) and the UA returning responses is
the User Agent Server (UAS). A SIP request, together with the responses it
triggers, is referred to as a SIP transaction.
SIP Responses
Upon reception of a request, a server issues one or several responses.
Range Response Class
100—199 Informational - Provisional Response
200—299 Success - Final Response of INVITE
300—399 Redirection
400—499 Client error
500—599 Server error
600—699 Global failure
SIP Requests
Every SIP request contains a field, called a
method, which denotes its purpose
INVITE
ACK
OPTIONS
BYE
CANCEL
REGISTER
Both requests and responses can contain SIP bodies. The body of a message
is its payload. SIP bodies usually consist of a session description
Example:
UA Client (Bob) called UA Server (Laura)
UA Client ----- invite------> UA Server
UA Client <-----180 Ringing-- UA Server (phone ringing)
UA Client <-----200 OK ------ UA Server (Off Hook/Recieve call)
UA Client ------ACK---------> UA Server
UA Client <---CONVERSATION--> UA Server
Three way handsake: INVITE-final response-ACK
ACK : ACKs are generated as final responses to an INVITE
Sending an ACK to every destination that has responded is essential to ensuring SIP operation over unreliable protocols such as UDP.
Errorneous case (taken care by ACK):
Bob would send an INVITE to Laura and retransmit it until it received
a final response from Laura. Until this final response is received, Bob cannot
know whether Laura received the INVITE or it got lost in the network.
Bob waits for a while and because he gets no answer, he gives up and
stops retransmitting the INVITE. Bob believes that no session has been
established.
At roughly the same time, Laura accepts Bob’s call and sends back a “200
OK” response. If this response gets lost, Bob will never receive it, so, Bob
still believes that no session has been established. Because Laura observes
that Bob has stopped retransmitting the INVITE, she assumes that Bob
has received her 200 OK. Therefore, Laura thinks that the session has been
successfully established
If a three-way handshake were in place for this scenario, Laura would
not receive an ACK for her 200 OK response, given that Bob gave up some
time ago. Thus, she would (correctly) think that the session was not established.
CANCEL
Let's say BOB called LAURA and waited for few rings and hangup as LAURA is not picking up the call
BOB -----------INVITE------------> LAURA
BOB <----------180 Ringing-------- LAURA (Phone ringing)
(Bob decided to hangup as he already waited for few rings)
BOB -----------CANCEL------------> LAURA
BOB <----------200 OK------------- LAURA (Reply back for CANCEL request)
BOB <--487 Transaction Cancelled-- LAURA (Reply for INVITE request)
BOB ------------ACK--------------> LAURA
CANCEL request is very useful when forking proxies are in the path. (pg 123)
Remember that a CANCEL request does not affect a transaction once a
final response has been sent.
BYE It is used to abandon sessions.
UA Client (Bob) called UA Server (Laura) and they started conversation. Then Laura went ON HOOK (Release the call)
UA Client ----- invite------> UA Server
UA Client <-----180 Ringing-- UA Server (phone ringing)
UA Client <-----200 OK ------ UA Server (Off Hook/Recieve call)
UA Client ------ACK---------> UA Server
UA Client <---CONVERSATION--> UA Server
UA Client <----- BYE -------- UA Server (abandon call)
UA Client -------200 OK-----> UA Server
REGISTER
BOB ---------REGISTER------> REGISTRAR
BOB <-------- 200 OK-------- REGISTRAR
OPTIONS
OPTIONS requests query a server about its capabilities.
One SIP server might answer to an OPTIONS request that it
supports SDP as session description protocol and five methods: INVITE,
ACK, CANCEL, BYE, and OPTIONS. Because the server does not support
the REGISTER method, I can deduce that it is not a registrar.
BOB ---------OPTIONS------> SIP SERVER
BOB <-------- 200 OK-------- SIP SERVER
Types of Proxy Servers
1. Call Stateful
2. Stateful
3. Stateless
1. Call Stateful
Call Stateful proxies need to be informed of all the SIP transactions that occur during the session and therefore, they are always in the path taken by SIP messages travelling between end users.
2. Stateful Proxy
Also known as Transaction Stateful Proxies because the transaction is their sole concern. e.g Forking Proxies
Proxy servers can only ACK non-successful final responses, which have a status code > 299
3. Stateless Proxy
Stateless proxes don't keep any state. They receive a request, forward it to the next hop, and immediately delete all state related to that request. It determines routing based solely on the Via header.
SIP uses text encoding as opposed to binary.
SIP is an application layer protocol.
By utilizing application layer time-outs with its retransmissions, an
application layer protocol can still exploit unreliable transport mechanisms (like UDP)
