Technical data
ServerIron ADX Advanced Server Load Balancing Guide 3
53-1002435-03
SIP overview
1
INVITE sip:user2@brocade.com SIP/2.0
Via: SIP/2.0/UDP pcuser1.brocade.com;branch=dkDKdkDKdkDK1111
Max-Forwards: 50
To: User2 <sip:user2@brocade.com>
From: User1 <sip:user1@brocade.com>;tag=1122334455
Call-ID: 12341234123412@pcuser1.brocade.com
CSeq: 123456 INVITE
Contact: <sip:user1@pcuser1.brocade.com>
Content-Type: application/sdp
Content-Length: 142
Because 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
Dynamic Host Configuration Protocol (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 field 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 field).
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 Session Description Protocol (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
example.
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:user2@brocade.com>;tag=dkdkdk1
From: User1 <sip:user1@brocade.com>;tag=1122334455
Call-ID: 12341234123412@pcuser1.brocade.com
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 (ACK) message 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 addresses 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.










