INVITE
Session Call Establishment

Call Flow

1. The UAC (Alice) sends an INVITE message to Bob (UAS).
2. The UAS receives the request and responds using 100 Trying.
3. The UAS sends message 180 Ringing response to UAC when the phone begins ringing.
4. Once the call is picked up, the UAS send a 200 Ok message to the UAC.
5. The UAC sends an ACK request to confirm the 200 Ok response was received.

Note: The ACK method completes what is known as the three-way handshake-confirmation that a session has been successfully established. In SIP the INVITE is the only method where this occurs, and this is due to the large gap of time that often occurs between the INVITE itself and the 200 OK response (when a user can’t find the phone, is running to the phone, etc.). So the ACK it is important: it tells the callee party that the caller hasn’t hung up and has accepted the call.

Real Example
Alice -> Bob

INVITE sip:41@pbx.company-alice-and-bob.com;user=phone SIP/2.0
Via: SIP/2.0/TLS 10.10.10.32:2061;branch=z9hG4bK-9gg3wzak;rport
From: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=g5ua0i7fz6
To: <sip:41@pbx.company-alice-and-bob.com;user=phone>
Call-ID: 3c2812339279-zvojwzvof6we
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:40@10.10.10.32:2061;transport=tls;line=i339wesg>;reg-id=1
P-Key-Flags: resolution=”31x13”, keys=”4”
User-Agent: snom360/7.3.14
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Content-Length: 452

Bob -> Alice

SIP/2.0 100 Trying
Via: SIP/2.0/TLS 10.10.10.32:2061;branch=z9hG4bK-9gohvng3wzak;rport=2061
From: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=g5ua0i7fz6
To: <sip:41@pbx.company-alice-and-bob.com;user=phone>;tag=eed7a3b4e0
Call-ID: 3c2812339279-zvojwzvof6we
CSeq: 1 INVITE
Content-Length: 0

Bob -> Alice

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 10.10.10.34:5060;branch=z9hG4bKe299f160c512cb066a3a536253aa4d44;rport=5061
From: "Bob" <sip:41@pbx.company-alice-and-bob.com>;tag=ozac09qwnh
To: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=1521860827
Call-ID: f6f17567@pbx
CSeq: 28592 INVITE
Contact: <sip:41@10.10.10.31:1037;transport=tls;line=zs4m8lei>;reg-id=1
Require: 100rel
RSeq: 1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0

Alice -> Bob

SIP/2.0 200 Ok
Via: SIP/2.0/TLS 10.10.10.34:5060;branch=z9hG4bK-08d0f56ed1e8d82deb32779c5a2cc55b;rport=5061
From: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=1521860827
To: "Bob" <sip:41@pbx.company-alice-and-bob.com>;tag=ozac09qwnh
Call-ID: f6f17567@pbx
CSeq: 28593 PRACK
Contact: <sip:41@10.10.10.31:1037;transport=tls;line=zs4m8lei>;reg-id=1
Content-Length: 0

Bob -> Alice

ACK sip:41@10.10.10.31:1037 ;transport=tls;line=zs4m8lei SIP/2.0
Via: SIP/2.0/TLS 10.10.10.34:5060;branch=z9hG4bK-6dcf1018159b8e96b7b6d62a758d77fd;rport
From: "Bob" <sip:41@pbx.company-alice-and-bob.com>;tag=ozac09qwnh
To: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=1521860827
Call-ID: f6f17567@pbx
CSeq: 28592 ACK
Max-Forwards: 70
Contact: <sip:41@10.10.10.34:5060;transport=tls>
Content-Length: 0

Att.: Note: The “user=phone” parameter indicates that the user portion of the URI (the part to the left of the @ sign) should be treated as a tel URI: so 40 is the number assigned to the Alice’s phone, and 41 to Bob’s phone. Generally if dial a telephone number on a keypad, this is converted into a SIP URI of the form sip:nnnnn@domain;user=phone (in this case Alice dialed 41 using the keypad of the her phone to call Bob).

REGISTER
While going through a typical SIP session the proxy servers do the job of finding out the exact location of the recipient, and must be knows the ip address of the recipient UA. What actually happens is that every user registers its current location to a REGISTRAR server. The application sends a message callee REGISTER informing the server of its present location. The Registrar stores this binding (between the user and its present address) in a location server which is used by other proxies to locate the user.

The register process is very important because permit to bind UA ↔ Ip Address where the UA itself answer to INVITE etc. In the registration process it is possible to use an authentication (realm, username, password), but it is not mandatory.

Real Example

Alice -> Registrar Server

REGISTER sip:10.10.10.110:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK97f7825d2
Max-Forwards: 70
Content-Length: 0
To: 40 <sip:40@10.10.10.110:5060>
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731226 REGISTER
Contact: 40 <sip:40@10.10.10.81:5060;transport=udp>;expires=120
Allow-Events: talk,hold,conference
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Authorization:Digest response="368b75e6f3d7244fbbf01da27b271feb",username="40",realm="asterisk",nonce="3b2d808b",algorithm=MD5,uri="sip:10.10.10.110:5060"
User-Agent: Aastra 9112i/1.4.3.1001 Brcm Callctrl/1.5.1.0 MxSF/v3.2.8.45

Registrar Server -> Alice

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK97f7825d2;received=10.10.10.81
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
To: 40 <sip:40@10.10.10.110:5060>;tag=as2efd2925
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731226 REGISTER
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7e318af4"
Content-Length: 0

Alice -> Registrar Server

REGISTER sip:10.10.10.110:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK824b13bb5
Max-Forwards: 70
Content-Length: 0
To: 40 <sip:40@10.10.10.110:5060>
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731227 REGISTER
Contact: 40 <sip:40@10.10.10.81:5060;transport=udp>;expires=120
Allow-Events: talk,hold,conference
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Authorization:Digest response="50d379545b2fd91e1a132eb42b120cf0",username="40",realm="asterisk",nonce="7e318af4",algorithm=MD5,uri="sip:10.10.10.110:5060"
User-Agent: Aastra 9112i/1.4.3.1001 Brcm Callctrl/1.5.1.0 MxSF/v3.2.8.45

Registrar Server -> Alice

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK824b13bb5;received=10.10.10.81
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
To: 40 <sip:40@10.10.10.110:5060>;tag=as2efd2925
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731227 REGISTER
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Expires: 120
Contact: <sip:40@10.10.10.81:5060;transport=udp>;expires=120
Date: Tue, 29 Nov 2011 00:29:34 GMT
Content-Length: 0

The authentication process checks that both communicate parties know a shared password. In the response 401 Unauthorized the server rejects the client registration and sends it back a challenge digest composed of an algorithm type, a realm and a nonce. When the client sends a new registration request but this time with a digest response composed of the:
”username”, “realm”, “nonce”, “uri”, “response” and the algorithm: the response is computed using the algorithm type, the nonce, the realm and the password. Now the server server will check the response using the password (that is the shared secret) 
for that user, and if all is correct it will send a OK message.

While going through a typical SIP session you have already seen that the caller doesn’t know the address of the callee initially. The proxy servers do the job of finding out the exact location of the recipient (ip address). What actually happens is that every user registers its current location to a REGISTRAR server. The application sends a message callee REGISTER informing the server of its present location. The Registrar stores this binding (between the user and its present ip address) in a location server which is used by other proxies to locate the user.

Att.: The Contact field in INVITE and others SIP-messages is related to the same field used in REGISTER method.

Att.: The ‘Expire’ field reflects the duration for which this registration (bind UA<->Ip Address) will be valid. So the UA has to refresh its registration from time to time.

OPTIONS
The SIP method 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 SIP methods, codecs, etc. without call the other party.

For example, before a client inserts a field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method !

Other use is to check the availability of an UA. I.e. it is possible bind statically an UA with a ip address: in this case the UA will not register himself. Using the OPTIONS message it is possible to verify that the UAS is on-line.

Att.: The UAs that register himself will receive the OPTIONS message too !

Real Example

The PBX send a OPTION message to an UA

OPTIONS sip:202@10.10.10.81:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK026408ff;rport
From: "Unknown" <sip:Unknown@10.10.10.110>;tag=as264d051f
To: <sip:202@10.10.10.81:5060;transport=udp>
Contact: <sip:Unknown@10.10.10.110>
Call-ID: 787c4d983b006a5a3011bd356140ed15@10.10.10.110
CSeq: 102 OPTIONS
User-Agent: FPBX-2.8.1(1.4.40)
Max-Forwards: 70
Date: Tue, 29 Nov 2011 00:29:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Response from UA

SIP/2.0 200 OK
Call-ID: 787c4d983b006a5a3011bd356140ed15@10.10.10.110
CSeq: 102 OPTIONS
From: "Unknown" <sip:Unknown@10.10.10.110>;tag=as264d051f
To: <sip:202@10.10.10.81:5060>;tag=4fe041f88ba9bed
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK026408ff;rport
Content-Length: 0
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Contact: <sip:202@10.10.10.81:5060;transport=udp>
Supported: replaces
User-Agent: Aastra 9112i/1.4.3.1001 Brcm Callctrl/1.5.1.0 MxSF/v3.2.8.45

In this case the UA inform that it exist and support the below SIP message.

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Att.: Generally OPTION is sent regularly to all UA from the PBX, whether they are registered or not (Ip Address binded statically to UA). In asterisk it is possible modify this behavior with the qualify parameter. If you turn on qualify in the configuration of a SIP device in sip.conf, Asterisk will send a SIP OPTIONS command regularly to check that the device is still online. If the device does not answer within the configured period (in ms) Asterisk considers the device off-line for future calls. This status can be checked by in Asterisk with the command sip show peers: this will provide status information for peers which have qualify=yes (in status information there is a column that show the delay in response to OPTION message, that is a measure in connection latency between device and Pbx).

Att.: It is possible to use OPTION to try to solve NAT problem in order to keep open the connection from Asterisk to the peer behind NAT. I will write about SIP Pbx protected by Firewall/NAT in future posts.

PREVIOUS POST: From Sip tot RTP (Part 3) – B2BUA… What ?!
NEXT POST:  From SIP to RTP (Part 5) – Trunks and surroundings