Overview Of SIP Operation I

1. basic functions of SIP (HTTP like request/response transaction model)
   
   
   1. Location of an endpoint
      
   2. signal of a desire to communicate
      
   3. negotiation of session parameters for the session
      
   4. teardown of session once established
      
2. Request handling in SIP is often classified as either INVITE or non-INVITE (an ACK is only sent in response to a response for an INVITE request,INVITE/200/ACK)
   
3. SIP messages are text-encoded
   

INVITE message example, with header fields (minimum required set)

1. INVITE sip:bob@biloxi.com SIP/2.0
   
2. Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
   
3. Max-Forwards: 70
   
4. To: Bob <sip:bob@biloxi.com>
   
5. From: Alice <sip:alice@atlanta.com>;tag=1928301774
   
6. Call-ID: a84b4c76e66710@pc33.atlanta.com
   
7. CSeq: 314159 INVITE
   
8. Contact: <sip:alice@pc33.atlanta.com>
   
9. Content-Type: application/sdp
   
10. Content-Length: 142
    

1. The INVITE request message (as given in the example above)
   
   
   1. line 1 contains the method name (INVITE in this case)
      
   2. line 2 has “Via”, the address at which Alice is expecting to receive the response, for this request, and a “branch” parameter which identifies the transaction
      
   3. line 3 has “Max-forwards”, the maximum number of hops a request can make to its destination, decremented on each hop
      
   4. line 4 has “To”, with a display name Bob and a Sip(s) URI, the user to which the request is intended
      
   5. line 5 has “From”, the originator of the request, with display name and his Sip(s) URI, and a random string parameter added by the softphone(endpoint) called “tag” used for identification purpose
      
   6. line 6 has “Call-ID”, a globally unique ID for this call, generated by combining a random string and the endpoint host name or IP address
      
      
      1. combination of To tag, From tag, and Call-ID defines a peer to peer SIP relationship called as a SIP dialog
         
   7. line 7 has “CSeq” or command sequence, an integer incremented for each new request within a dialog
      
   8. line 8 has “Contact”, contains the direct URI that represent a direct route to the contact Alice (originator of the request)
      
      
      1. usually composed of username at a FQDN (fully qualified domain name), but can contain IP address
         
      2. contact tells other elements (endpoints,proxies etc) where to send future requests
         
   9. line 9 has “Content-Type”, contains a description of the message body (not shown)
      
   10. line 10 has “Content-Length”, contains byte count of the message body
       
2. The details of the session like media type, codec or sampling rate, are described using some other protocol (like SDP), and is mentioned in the “Content-Type” and the length is mentioned in the “Content-Length” field
   
3. Alice soft phone does not know the location of the Bob soft phone, or the proxy in the biloxi.com domain the INVITE is send to the proxy in Alice domain i.e. atlanta.com. these proxy server address are to be configured in the Alice Soft-phone.
   
4. This server which is called as proxy, receives the INVITE request and sends 100 (Trying) response back to Alice soft phone. 100 (trying) response indicates that the INVITE has been received by the proxy and proxy is working on behalf to route the INVITE to the destination.
5. This SIP response contains the same To, From,Call-ID, CSeq and branch parameter in the Via as the INVITE
6. Before forwarding the INVITE request to the biloxi.com proxy, the atlanta.com proxy adds a additional Via header field value that contains its own address
7. The biloxi.com proxy receives the INVITE and responds with a 100(trying) reponse to atlanta.com proxy.
8. The biloxi.com proxy consult a location service, that contain the current  IP address of Bob, adds a Via header containing its own address and proxies it to the Bob softphone.
9. On ringing the Bob Softphone respondes with a 180(ringing) response, which is routed back through the two proxies using the Via header (which is removed by each proxy on the way back) added by each proxy to the Alice softphone.
10. This ensures that each proxy that sees the INVITE also sees the response to the INVITE
11. If Bob picks up the phone, his SIP phone sends a 200(OK) response (with a message body with the SDP media description) back to Alice, to indiacte that the call has been answered.
12. This two phase exchange provides basic negotiation capabilities, and is the basis of the offer/answer model of SDP exchange.
the 200(ok)which Bob sends look like this (SDP not shown)
1. SIP/2.0 200 OK
2. Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8;received=192.0.2.3 (added by biloxi.com proxy)
   
3. Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 (added by atalanta.com proxy)
   
4. Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=192.0.2.1 (added by Alice SIP phone)
5. To: Bob <sip:bob@biloxi.com>;tag=a6c85cf (this tag is added by bob phone)
   
6. From: Alice <sip:alice@atlanta.com>;tag=1928301774
7. Call-ID: a84b4c76e66710@pc33.atlanta.com
8. CSeq: 314159 INVITE
9. Contact: <sip:bob@192.0.2.4> (bob can be directly reached at his SIP phone)
   
10. Content-Type: application/sdp
11. Content-Length: 131
13. The first line of the response contains the response code (200) and the reason phrase (OK).
    
14. The Via,To,From,Call-ID,and Cseq header fields are copied from the INVITE request
15. The tag added by bob phone to the To header, will be incorporated by both endpoints into dialog and will be included in all future request and response in this call.
16. proxy servers can make flexible "routing decisions" to decide where to send a request, and can also send a INVITE to a number of locations at the same time. This parallel search is known a forking
17. On receiving the 200(OK) from Bob, the Alice SIP phone sends an ACK to Bob SIP phone to confirm the reception of the final response. This ACK is send directly to the Bob by using the address in the contact header field of 200(OK) response.
18. Both the Alice and Bob SIP phones have learned each other address from the contach header fields of INVITE/200(OK).
    
19. This completes the three way handshake , INVITE/200/ACK and the SIP session is established between Alice and Bob
20. As the media session has begin between Alice and Bob SIP phones, these end-to-end media packets takes a different path from the SIP signalling messages.
21. If during the media session either Alice or Bob deicides to change the characteristics of media session , a re-INVITE is send, referencing the existing dialog.
22. This re-INVITE is responded by a 200(OK) from the other party if the changes are acceptable, and the requester responds with a ACK for this 200(OK).
23. If the changes proposed by the re-INVITE are not acceptabe to other party then an error response such as 488(Not Acceptable Here) is send, which is also responded by an ACK.
24. Tha failure of the re-INVITE does not ends the existing media session, and the session continues using the previously negotiated characteristics.
25. At the end of the call Bob hangs up first and generates a BYE message, send directly to Alice SIP phone. The receipt of this BYE is confirmed with a 200(OK) response from Alice SIP Phone, which terminates the session and the BYE transaction. There in no ACK for this 200(OK).