Bob发送的200(OK)应答可能是这样的：
SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) |
应答的第一行包含一个应答代码(200)和一个解释短语(OK)。其它行就是应答的头域。Via，To，From，Call-ID和CSeq头域的值都从INVITE请求拷贝而来(这时候应该有3个Via头域，分别由Alice的SIP软电话，atlanta.com代理服务器，和biloxi.com代理服务器添加)。Bob的SIP电话添加一个tag参数到To头域。以后所有的属于这个对话的请求和应答都要包含这个tag参数。
当Alice的软电话接收到这个200(OK)应答后，马上停止响铃并显示呼叫已经被接听了。最后，Alice发送一个确认信息(ACK)给Bob的SIP电话，表示自己收到了最终应答(200(OK))。这个例子中的最终应答由Alice直接发送给了Bob，这是因为Alice的软电话从Contact头域里面可以得到Bob的地址信息。通过INVITA/200/ACK的三步握手，SIP会话就建立起来了。关于SIP会话建立的详细步骤请参看RFC3261第13节。
现在Alice和Bob的多媒体会话已经建立起来了，他们可以发送通过SDP协商好的格式的媒体数据了。一般来说，媒体数据包的传输与SIP消息的传输采用不同的通信方式。SIP消息大多通过代理服务器转发，而媒体数据多使用点对点的传输。
在会话过程中，无论是Alice还是Bob决定改变这个媒体会话，都要通过发送一个re-INVITE请求。这个re-INVITE请求包含新的媒体描述(可能是SDP)，它不会建立新的会话，而是修改当前已经存在的会话。对方接收到这个请求后，发送一个200(OK)同意这个改变，最后请求者发送ACK。如果对方不同意这个修改，可能会发送一个错误应答，比如488(不接受)。但是这个失败应答不会使已存在的会话退出，而是继续使用以前协商的媒体进行通信。关于修改一个会话的详细说明，请参看RFC3261第14节。
最后，Bob发送BYE消息挂断电话。BYE消息直接发送到Alice的软电话。Alice发送200(OK)确定接收到了BYE消息，并且终止这个会话。Bob不用发送ACK，因为ACK只有在接收到对INVITE的应答时才被发送。关于终止一个会话更详细的说明，请参看RFC3261第15节。
还有一个问题就是关于biloxi.com服务器如何获得Bob的位置。Bob的SIP电话开机的时候会向一个注册服务器发送REGISTER消息。REGISTER消息的作用是将Bob的SIP URI或者SIPS URI与Bob当前使用的电话地址进行绑定，并将这个绑定信息保存到数据库中，这被称之为定位服务(location service)。biloxi.com代理服务器使用定位服务获得Bob的地址。注册服务器、代理服务器、定位服务器都是逻辑上的服务器，而不是物理上的服务器，所以他们可以位于同一台服务器上。
