---------------------------------------------------------------------------------------------------------------------------

SIP

---------------------------------------------------------------------------------------------------------------------------

This week I was primarily going through the last Lecture’s materials.

From the references the Session Initiation Protocol (SIP) is a relatively simple peer-to-peer ASCII-based protocol that uses requests and responses to establish communication among the various components in the network and to ultimately establish a conference between two or more end points. It involves user agent client (UAC)—A client application that initiates the SIP request and user agent server (UAS)—A server application that contacts the user when a SIP request is received and that returns a response on behalf of the user

SIP clients include:

• Phones—Can act as either a UAS or UAC. Softphones (PCs that have phone capabilities installed) and Cisco SIP IP phones can initiate SIP requests and respond to requests.
• Gateways—Provide call control. Gateways provide many services, the most common being a translation function between SIP conferencing endpoints and other terminal types. This function includes translation between transmission formats and between communications procedures. In addition, the gateway translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side.

SIP servers include:

• Proxy server—The proxy server is an intermediate device that receives SIP requests from a client and then forwards the requests on the client's behalf. Basically, proxy servers receive SIP messages and forward them to the next SIP server in the network. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission, and security.
• Redirect server—Provides the client with information about the next hop or hops that a message should take and then the client contacts the next hop server or UAS directly.
• Registrar server—Processes requests from UACs for registration of their current location. Registrar servers are often co-located with a redirect or proxy server.

Figure 1-1: SIP Architecture

Users register with a registrar server using their assigned SIP addresses. The registrar server provides this information to the location server upon request.

When a user initiates a call, a SIP request is sent to a SIP server (either a proxy or a redirect server). The request includes the address of the caller (in the From header field) and the address of the intended callee (in the To header field). The following sections provide simple examples of successful, point-to-point calls established using a proxy and a redirect server.

Over time, a SIP end user might move between end systems. The location of the end user can be dynamically registered with the SIP server. The location server can use one or more protocols (including finger, rwhois, and LDAP) to locate the end user. Because the end user can be logged in at more than one station and because the location server can sometimes have inaccurate information, it might return more than one address for the end user. If the request is coming through a SIP proxy server, the proxy server will try each of the returned addresses until it locates the end user. If the request is coming through a SIP redirect server, the redirect server forwards all the addresses to the caller in the Contact header field of the invitation response.

For more information, see RFC 2543—SIP: Session Initiation Protocol, which can be found at http://www.faqs.org/rfcs/.

Next Figure shows the interaction between a User Agent Client (UAC) and a User Agent Server (UAS) during trivial session establishment and termination:

Section Establishment And Termination

The session establishment call flow proceeds as follows:

1. The calling User Agent Client sends an INVITE message to Bob’s SIP address: sip:bob@acme.com. This message also contains an SDP packet describing the media capabilities of the calling terminal.

2. The UAS receives the request and immediately responds with a 100-Trying response message.

3. The UAS starts “ringing” to inform Bob of the new call. Simultaneously a 180 (Ringing) message is sent to the UAC.

4. The UAS sends a 182 (Queued) call status message to report that the call is behind two other calls in the queue.

5. The UAS sends a 182 (Queued) call status message to report that the call is behind one other call in the queue.

6. Bob picks up the call and the UAS sends a 200 (OK) message to the calling UA. This message also contains an SDP packet describing the media capabilities of Bob’s terminal.

7. The calling UAC sends an ACK request to confirm the 200 (OK) response was received.

The session termination call flow proceeds as follows:

1. The caller decides to end the call and “hangs-up”. This results in a BYE request being sent to Bob’s UAS at SIP address sip:bob@lab.acme.com

2. Bob’s UAS responds with 200 (OK) message and notifies Bob that the conversation has ended.

CALL REDIRECTION

1. First a SIP INVITE message is sent to bob@acme.com, but finds the Redirect server sip.acme.com along the signaling path.

2. The Redirect server looks up Bob’s current location in a Location Service using a non-SIP protocol (for example, LDAP).

3. The Location Service returns Bob’s current location: SIP address 3573572@gwtelco.com.

4. The Redirect Server returns this information to the calling UAC using a 302 (Moved Temporarily) response. In the response message it enters a contact header and sets the value to Bob’s current location, 3573572@gwtelco.com.

5. The calling UAC acknowledges the response by sending an ACK message.

6. The calling UAC then continues the transaction directly with gw.telco.com by sending a new INVITE.

7. gw.telco.com is able to notify Bob’s terminal of the call and Bob “picks up” the call. A 200 (OK) response is sent back to the calling UAC.

8. The calling UAC acknowledges with an ACK message.

CALL PROXYING

1. An INVITE message is sent to bob@ acme.com, but finds the Proxy server sip.acme.com along the signaling path.

2. The Proxy server immediately responds with a 100 (Trying) provisional response.

3. The Proxy server looks-up Bob’s current location in a Location Service using a non-SIP protocol (For example, LDAP).

4. The Location Service returns Bob’s current location: SIP address bob@lab.acme.com.

5. The Proxy server decides to proxy the call and creates a new INVITE message based on the original INVITE message, but with the request URI in the start line changed to bob@lab.acme.com. The Proxy server sends this request to the UAS at lab.acme.com.

6. The UAS responds first with a 100 (Trying).

7. The UAS responds with a 180 (Ringing) response.

8. The Proxy server forwards the 180 (Ringing) response back to the calling UA.

9. When the call is accepted by the user (for example, by picking up the handset) the UAS at lab.acme.com sends a 200 (OK) response. In this example, Bob’s UAS inserts a Contact header into the response with the value bob@lab.acme.com. Further SIP communication will be sent directly to it and not via the Proxy Server. This action is optional.

10. The Proxy forwards the 200 (OK) response back to the calling UAC.

11. The calling UA sends an ACK directly to Bob’s UA at the lab (according to the Contact header it found in the 200 (OK) response).