接历史文档。
12.3 Termination of a Dialog
Dialog的结束流程独立于此method的使用环境,如果一个外部dialog请求生成了一个非2xx最终响应,任何通过以前请求响应创建的历史dialogs将会结束。结束确认dialogs的机制是依赖于具体的method。在此规范中,BYE method 将会结束和它关联的会话和此dialog。具体细节参考请Section 15。
![](http://www.ctiforum.com/uploadfile/2020/0929/20200929095221848.jpg)
13 Initiating a Session
13.1 Overview
当一个用户代理客户端期望发起一个会话(例如,语音,视频或者游戏)时,它会发送一个INVITE请求。这个INVITE请求将会询问服务器端来创建一个会话。这个请求可能会通过代理进行转发,最后抵达一个或者多个UAS端,此UAS端是最终接受此请求的服务器端。这些UAS端将需要定期查询此用户端,确认是否接受此邀请请求。
一定时间后,那些UAS端返回一个2xx响应表示能够接受此邀请(表示此会话已被创建)。如果此邀请没有被接受的话,UAS将会对用户代理发送一个3xx,4xx,5xx或者6xx响应,状态错误码发送取决于被拒绝的理由。在UAS发送最终响应之前,UAS也能发送一个临时响应(1xx),通知对方正在联系被呼叫方来处理UAC流程。
在收到一个或多个临时响应后,UAC将会获得一个或者多个2xx响应,或者一个非-2xx最终响应。因为需要耗费一定的时间等待接收邀请的最终响应消息,邀请(Invite )事务的可靠性机制处理方式和其他的请求(OPTIONS)有所不同。一旦UAC收到一个最终响应,此UAC需要对每个它收到的最终响应发送一个ACK确认消息。发送ACK的流程处理取决于响应的类型。对于介于300和699之间的最终响应,ACK的处理是在事务层来完成对,并且需要遵从一系列规则(具体规则参考Section 17)。对于2xx响应,ACK是由UAC core来生成。
由INVITE收到的2xx响应创建一个会话,同时它也在UA之间创建了一个dialog。一个UA是发起此INVITE请求的,一个UA是生成2xx响应的。因此,当从不同远端UA收到多个2xx响应(因为INVITE分叉),每个2xx创建一个不同的dialog。所有这些dialog都属于同一呼叫。
此章节提供了一个使用INVITE创建会话的细节。支持INVITE的UA也必须支持ACK,CANCEL和BYE。
13.2 UAC Processing
13.2.1 Creating the Initial INVITE
因为初始请求表示一个dialog外部请求,它的构建过程遵从Section 8.1.1 章节的处理流程。对于此INVITE具体情况来说,需要增加额外的步骤。
- 任何Allow头域(Section 20.5)应该出现在此INVITE中。它表示在一个dialog生命周期内,UA发送此INVITE时援引了何种methods。例如,在dialog中,UA接收INFO请求的能力应该[34]包含一个Allow头,此Allow头列出此NFO method。
- 任何Supported头域(Section 20.37)应该出现在此INVITE中。它枚举了UAC可以理解的所有拓展。
- 任何Accept头域(Section 20.1)也可能出现在INVITE中。它表示UA可以接受何种 Content-Types,接受Content-Types的方向不仅是UA接收响应侧,而且还在由此INVITE创建的dialog中的后续请求侧。Accept头域非常有用,它原来表示各种会话描述格式的支持能力。
UAC可以增加一个Expires头域(Section 20.19)来限制请求的有效性。如果在Expires头中的时间设置超时,没有收到此INVITE的最后应答响应,UAC core应该对此INVITE生成一个CANCEL请求,参考Section 9章节。
UAC也可以发现其他有用的头域添加到头域中,其中包括 Subject(Section 20.36), Organization(Section 20.25)和User-Agent(Section 20.41)头域。所有这些头域包含和INVITE相关的信息。
UAC可以对此INVITE添加一个消息体。Section 8.1.1.10 具体描述了如何构建头域--Content-Type,和需要说明消息体内容。
针对包含会话描述的消息体,规范有一些特别的规则,消息体相应的Content-Disposition是一个“会话”。SIP使用offer/answer模式支持UA发送一个会话描述,称之为offer端,offer端包含了此会话的推荐的描述。此offer端指示它所期望的通信方式(语音,视频或者游戏), 通信方式所支持的参数(例如编码类型)和从应答方接收媒体的地址。对端UA则携带另外一个会话描述做出响应,称之为answer,它指示何种媒体方式可以被接受,所支持媒体方式的参数和从提供方接收媒体的地址。offer/answer交互是在dialog的context中进行,因此,如果SIP INVITE导致了多个dialog的话,每个dialog就是一个独立的offer/answer交互。当发生offer和answer时,此offer/answer描述规定了限制条件(例如,当一个offer正在处理时,用户不能创建一个新的offer)。通过这样的处理方式,在SIP消息中的offer和answer双方能够体现这样的限制措施。在此规范中,offers和answers仅能够出现在INVITE请求,响应和ACK中。这里,关于offers和answers模式有进一步的限定。对于初始INVITE事务,规则包括:
- 初始offer必须是在一个INVITE中,或没有在INVITE中,如果没有的话,初始offer是在从UAS返回UAC的第一个可靠的非失败消息中。在此规范中是2xx 最终响应。
- 如果初始响应在INVITE中,应答必须是在从UAS返回到UAC的一个可靠非失败消息中,UAC和那个INVITE有关联关系。对于此规范来说,仅表示为此INVITE的2xx最终响应。同样相似的应答也可以被置于任何临时响应中,这些临时响应是发送到前面应答方的响应。UAC必须把它收到的第一个会话描述视为此应答方,并且必须忽略任何在针对此初始INVITE的后续响应中的会话描述。
- 如果此初始offer是在从UAS返回到UAC的第一个可靠非失败消息中,从 answer必须是在此消息的确认消息中(在此规范中,ACK支持的2xx响应中)。
- 对第一个offer来说,如果UAC已发送或已收到一个应答后,此UAC可能在请求中生成后续的offer,这些请求的处理是基于那个method指定的规则来进行的,但是,此处理方式仅支持两种状态,第一种是如果UAC已经收到了前面offer的应答后的状态,和如果UAC没有获得应答,它不发送任何offer的状态。
- 对初始offer来说,一旦UAS发出或收到了应答,此UAS一定不能在对初始请求的响应中生成后续的offer。这表示,直到此初始事务完成前,基于此规范的UAS永远不能单独生成后续的offer。
具体来说,以上规则中,对此规范单独指定了两个交互来支持UA的法则-offer是在INVITE中, answer 是在2xx响应中(也可能在1xx响应中)或者offer是在2xx响应中,answer是在ACK中。所有支持INVITE的代理必须支持它们的这两个交互。
所有用户代理必须支持Session Description Protocol (SDP) (RFC 2327 [1])作为一种手段来描述会话,它们构建offer和answer的方式必须遵从此流程,这个流程在定义在[13]章节。
此offer-answer模式的限制所描述的仅应用在消息体中,此消息体的Content-Disposition头值是一个“会话”。因此,INVITE和ACK中包含一个消息体是可能的,例如,一个INVITE中包含一张图片(Content-Disposition: render),并且从ACK是一个会话描述(Content-Disposition: session)。
如果此Content-Disposition 头域值丢失的话,Content-Type application/sdp的消息体会说明这个disposition "session",其他的内容类型会说明"render"值。
一旦INVITE创建后,UAC遵从一个处理机制,这个机制在第八章的dialog外部发送请求的章节中定义。这样会导致一个客户端的事务构建,此事务构建最终发送此请求并且对UAC返回响应。