a Tesla <sip:n.tesla@high-voltage.org>;tag=76341 Call-ID: 23456789@lab.high-voltage.org CSeq: 1 ACK Content-Length: 0 The command sequence, CSeq, has the same number as the INVITE, but the method is set to ACK. At this point, the media session begins using the media information carried in the SIP messages. The media session takes place using another protocol, typically RTP. The branch parameter in the Via header field contains a new transaction identifier than the INVITE, since an ACK sent to acknowledge a 200 OK is considered a separate transaction. This message exchange shows that SIP is an end-to-end signaling protocol. A SIP network, or SIP server is not required for the protocol to be used. Two end points running a SIP protocol stack and knowing each other's IP addresses can use SIP to set up a media session between them. Although less obvious, this example also shows the client-server nature of the SIP protocol. When Tesla originates the INVITE request, he is acting as a SIP client. When Marconi responds to the request, he is acting as a SIP server. After the media session is established, Marconi originates the BYE request and acts as the SIP client, while Tesla acts as the SIP server when he responds. This is why a SIP-enabled device must contain both SIP server and SIP client software-during a typical session, both are needed. This is quite different from other client-server Internet proto- cols such as HTTP or FTP. The Web browser is always an HTTP client, and the Web server is always an HTTP server, and similarly for FTP. In SIP, an end point will switch back and forth during a session between being a client and a server. In Figure 2.1, a BYE request is sent by Marconi to terminate the media session: BYE sip:n.tesla@lab.high-voltage.org SIP/2.0 Via: SIP/2.0/UDP tower.radio.org 5060; branch=z9hG4bk392kf Max-Forwards: 70 To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341 From: G. Marconi <sip:marconi@radio.org>;tag=a53e42 Call-ID: 123456789@lab.high-voltage.org CSeq: 1 BYE Content-Length: 0 Introdu