分类： 嵌入式
2011-03-24 16:08:52
当Alice的softphone收到180（Ringing）应答的时候，它提示Alice,可能是通过一个回铃音，或者屏幕上的一个消息提示。
在这个例子中，Bob决定响应这个呼叫。当他拿起电话，他的SIP电话发送200（OK）回应给发送者，表示这个电话已经接起来了。这个200（OK）包含了一个消息体，这个消息体包含SDP媒体描述，这个媒体描述包含Bob希望和Alice建立何种媒体连接。同样，SDP消息也是两段交换：Alice发送一个给Bob，Bob发送一个回给Alice。这个两段的交换提供基本的兼容性协商，并且基于简单的SDP提出/应答交换模型。如果Bob不想响应这个呼叫或者正在响应别的呼叫，一个错误的响应会代替正常的200（OK）回送出去，这样，就不会有连接建立。SIP完整的返回代码在21节有介绍。Bob发出的200（OK）（图一的F9消息）可能长得像这样的：
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=z9hG4bK77ef
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)
应答的第一行包含了应答代码（200）和原因（ok）。剩下的行包含了包头域。VIA,TO,FROM,CALL-ID,Cseq包头域是从INVITE请求包中直接拷贝过来的。（有三个VIA域值－一个是Alice SIP电话增加的，一个是atlanta.com代理加的，一个是biloxi.com代理加的）。Bob的SIP电话增加了一个TAG参数。这个TAG参数会被参与对话的各方所使用，并且在以后的对话中被使用。Contract域包含了一个能直接联系到Bob的URI。Content－type和Content_Length域包含了消息体（没有在例子中体现），这个消息体里边是Bob的SDP媒体信息。
除了DNS和位置服务之外，代理服务器可以自主决定路由，也就是说自己决定应该向哪里转发请求。比如，如果Bob的SIP电话返回一个486（电话正忙）信号，biloxi.com这个代理服务器可以转发这个INVITE请求到Bob的语音邮箱服务器。一个代理服务器可以同时向N个地方发送INVITE请求。这种并发寻找就是传说中的分流（forking）。
在这个例子中，200（OK）应答通过两个代理并且发送到Alice的softphone上，Alice的softphone收到这个应答，停止振铃，并且标志电话Bob已经接听。最后，Alice的电话发送一个确认消息，ACK，到Bob的SIP电话来确认接收到了这个最后的200（o’k）应答。在这个例子中，ACK信号是直接由Alice的softphone发送到Bob的SIP phone上，跨过了两个代理服务器。这是因为两个端点（Alice和Bob）通过INVITE/200(OK)的请求应答包中的Contact包头域都知道互相之间的地址了，这个地址是最开始发起INVITE请求的时候所不知道的。所以，不需要两个代理服务器再查找对方的地址了，所以代理服务器不参与接下来的通话流了。这就完成了一个完整的使用INVITE/200/ACK 三方握手来建立SIP会话的过程。会话建立过程中的细节描述再13节由描述。
现在，Alice和Bob的媒体会话开始了，他们通过发送刚才建立会话所交换的SDP包中约定的互相明白的媒体包来进行会话。一般情况下，端到端的媒体包和SIP信号控制包通过不同的通讯路径来发送。
在会话中，Alice或者Bob都可以改变他们自己的媒体会话属性。这个可以通过发送一个包含新媒体属性描述的re-INVITE请求来完成。这个re-INVITE是捆绑在一个现有的会话的，这样参与会话的对方可以明白这是要改变现有的会话属性而不是新建立一个会话。对方收到这个re-INVITE请求后，会发送一个200（OK）应答表示接受这个改变。请求方通过一个ACK来表示接受了对方的这个200(OK)应答。如果对方不同意这个媒体属性变化，他会发送一个错误的应答比如488（暂时不能进行），这个也会收到发起者的一个ACK响应。不管怎样，就是是re-INVITE的失败也不会影响到现有的会话－原有的会话还可以用上次的媒体会话属性继续。可以在14节找到会话属性更改的细节说明。
在通话结束的时候，Bob首先断开（挂机hangs up），并且发送一个BYE的消息。这个BYE的消息将直接送到Alice的softphone，同样是跳过代理的。Alice通过发送200（OK）应答来确认收到了这个BYE消息，这个消息终止了会话并且应答了BYE的请求。ACK在这里不需要发送－一个ACK信号只在响应一个INVITE的响应的时候被发送。我们稍晚一点会讨论这个INVITE的特别处理，但是基于SIP的可靠性的机制，一个通话的时间可以认为包含电话振铃和挂机的时间（but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking.）基于这样的原因，SIP请求的处理通常根据是否INVITE请求进行分类，INVITE类和非INVITE类请求分开处理。结束会话的细节可以在15节查到。
24.2节描述了图1中使用的全部消息详细解释。在某些情况下，所有会话中的包都继续通过代理转发会很有用。比如，如果biloxi.com代理服务器希望在INVITE之后继续保持SIP消息流，他会在INVITE中增加一个头域（Record-Route）包含一个URI指向这个代理服务器的hostname或者IP地址。这个消息会被Bob的SIP电话和Alice的softphone所接到（因为Record-Route头域将在200(OK)应答中被送回），并且在会话中一直保存。那么biloxi.com代理服务器就可以继续接收和转发ACK,BYE,给BYE的200（OK）应答。每一个代理都可以单独决定是否接收INVITE以后的后续消息，并且这些后续消息都可以被发送到那些决定接收后续消息的代理服务器。这种情况通常发生在提供mid-call业务的代理服务器上。
登记服务是另一个常用的SIP操作。登记服务是biloxi.com代理服务器知道Bob当前地址的一个方法。在初始化的时候，或者每隔一段时间，Bob的SIP 电话发送REGISTER消息给biloxi.com的一个注册服务器。REGISTER消息包含了Bob当前登陆服务器的SIP或者SIPS的URI（sip:bob@biloxi.com）（转换成为Contact域中的SIP或者SIPS URI）。登记服务器登记这个映射，这个叫做绑定（binding），写到一个数据库里边，叫做定位服务（location service），这个数据库可以被biloxi.com的代理服务器使用。通常登记服务器和代理服务器是做在一起的。一个很重要的概念就是SIP服务器的差别在逻辑上，并非在物理上的差别。
Bob并没有限定非得在一个单个设备上发起注册。比如，他家里的SIP电话和公司的SIP电话都可以注册。这些消息在定位服务（location service）中保存，并且允许代理服务器通过不同的手段查找Bob。同样的，不同的用户也可以在同一个设备上同时注册。
定位服务（location service）是一个逻辑概念。他是让代理服务通过输入一个URI来查询到底应该向哪里转发请求。可以简单通过用户注册来建立这个定位服务所需要的资料，也可以通过其他方法。可以通过其他任意的地址映射方式来实现定位服务。
最后在SIP中需要注意的是，注册服务只是用来提供路由收到的SIP请求的，它并不做请求的身份认证的判定。在SIP中授权和认证可以通过建立在基于请求/应答的模式上的上下文相关的请求来实现，也可以使用更底层的方式来实现（具体在26节有描述）。
完整的注册SIP消息描述例子在24.1节。
其他SIP的操作，比如检查SIP服务器的负载，或者使用客户端使用可选项（OPTIONS），或者用CANCEL取消一个未决的请求，在后续的章节中会介绍
