Technical data

ServerIron ADX Advanced Server Load Balancing Guide 3
53-1002435-01
SIP Overview
1
Content-Length: 142
Since User1's SIP phone does not know the location of User2's SIP phone, it sends the INVITE
message to the SIP proxy server that is serving the brocade.com domain. The address of the
brocade.com proxy server is known to the SIP phone through static configuration or through DHCP.
The proxy server receives the INVITE request and sends a 100 (Trying) response back to User1's
SIP phone. This response contains the same To, From, Call-ID, CSeq and branch parameter in the
Via as the INVITE, which allows User1's SIP phone to correlate this response to the previously sent
INVITE. The proxy server consults a database, generally called a location service, that contains the
current IP address of User2. It then forwards (or proxies) the INVITE request there. Before
forwarding the request, the proxy server adds an additional Via header field value with its own
address (the INVITE already contains User1's address in the first Via).
User2's SIP phone receives the INVITE and alerts User2 of the incoming call from User1, that is,
User2's phone rings. User2's SIP phone indicates this by a 180 (Ringing) response, which is routed
back through the SIP proxy server in the reverse direction. When User1's SIP phone receives the
180 (Ringing) response, it passes this information to User1, using an audio ringback tone.
If User2 decides to answer the call (User2 picks up the handset), the SIP phone sends a 200 OK
response to indicate that the call has been answered. The 200 OK contains the Via, To, From,
Call-ID, and CSeq header fields that are copied from the INVITE request, and a message body with
the SDP media description of the type of session that User2 is willing to establish with User1. The
200 OK (message F6 in Figure 1) would look like the following.
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcproxy.brocade.com
;branch= dkDKdkDKdkDK2222;received=172.1.1.2
Via: SIP/2.0/UDP pcuser1.brocade.com
;branch= dkDKdkDKdkDK1111;received=172.1.1.1
To: User2 <sip:[e-mail]>;tag=dkdkdk1
From: User1 <sip:[e-mail]>;tag=1122334455
Call-ID: [e-mail]
CSeq: 123456 INVITE
Contact: <sip:user2@172.1.1.3>
Content-Type: application/sdp
Content-Length: 131
The 200 OK message is routed back through the SIP proxy server to the User1's SIP phone, which
then stops the ringback tone and indicates that the call has been answered. Finally, User1's SIP
phone sends an acknowledgement message, ACK, to User2's SIP phone to confirm the reception of
the final response (200 OK). This ACK is sent directly from User1's SIP phone to User2's SIP phone,
bypassing the SIP proxy server. This occurs because the endpoints have now learned each other's
IP address from the Contact header fields through the INVITE/200 OK exchange, which was not
known when the initial INVITE was sent. This completes the INVITE/200/ACK three-way handshake
used to establish SIP sessions.
User1 and User2's media exchange now begins using the format that they have agreed upon
through SDP. In general, the end-to-end media packets take a different path from the SIP signaling
messages. At the end of the call, User2 disconnects (hangs up) the phone and generates a BYE
message. This BYE is routed directly to User1's SIP phone, again bypassing the SIP proxy. User1
confirms receipt of the BYE with a 200 OK response, which terminates the session and the BYE
transaction. No ACK is sent. (An ACK is only sent in response to an INVITE request.)