文章目录
- 注册(REGISTER)
- 1、AOR和Contact区别
- 2、注册概述
- 3、注册与定位服务
- 4、注册超时处理
- 5、注册消息
- 6、多Contact地址处理
- 7、下期预告
注册(REGISTER)
1、AOR和Contact区别
在学习注册之前,首先区分一下AOR和Contact两个概念。我们通常所说的SIP地址中包括了AOR和Contact两种类型的地址。
AOR的全称是Address-of-Record。在RFC3261中,AOR是这样定义的: Address-of-Record: An
address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the “public address” of the user.
记录地址 (AOR) 是一个 SIP 或 SIPS URI,它指向具有位置服务的域,该位置服务可以将 URI 映射到用户可能可用的另一个 URI。通常,位置服务通过注册进行实现。AOR通常被认为是用户的“公共地址”。
The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs.
Contact头域字段值包含 UA 希望接收请求的 URI,并且即使在任何对话之外的后续请求中使用,此 URI 也必须有效。
简单来说,两种地址的格式也是完全不同的。AOR地址格式为SIP:user@domain(例如,SIP:james@hiastar.com),而Contact地址格式为Contact: james 。大家可能注意到了,这个Contact是一个具体的IP地址,一些情况下也可能是一个FQDN地址。
下面,让我们详细说明一下两种地址的不同。
首先,如果讨论AOR地址的话,我们可以使用我们互联网的域名和IP地址的关系来说明。大家知道,一般用户访问网站使用的是公司的域名,而不是公司网站的IP地址。域名需要通过解析以后,才能获得相应的IP地址。因此,AOR简单来说,就是一个带域名的用户帐户,相当于一个用户的公网地址,它具有唯一性,而Contact的具体的联系方式是这个终端的IP地址。但是,一定要明白,SIP终端的IP地址可能是临时性的,终端也可能是完全移动的,而且支持了不同的物理形式,这里就需要SIP服务器做定位处理,和其AOR记录地址匹配。实际上,用户需要首先呼叫AOR地址,而不是Contact地址。
读者需要记住AOR和Contact的区别:
- AOR 地址是表示我是谁,表示用户本身的身份,带域名的地址。
- Contact地址表示的是我在哪里,表示SIP终端用户的具体的物理IP地址和端口。
- 双方可以通过已获悉的Contact地址直接进行呼叫(点对点方式)。
- AOR地址必须可以解析为Contact地址。
- Contact地址必须是可路由的地址,对端可发后续请求到此地址,例如我们下面要讲的ACK。
- 一个AOR地址可以对应多个Contact地址(一个SIP终端可以支持多种形式的物理终端)。
当然,为了让用户自己获悉地方的地址和呼叫,首先,双方SIP终端必须注册到SIP服务器,SIP终端呼叫对方之前,需要先通过SIP注册服务器进行状态检查,然后才能进行呼叫,路由管理和会话处理。接下来,我们介绍如何实现SIP注册服务。
2、注册概述
SIP终端用户首先对SIP进行注册服务,同时对注册服务器发送AOR地址和Contact地址。注册服务器判断其域名是否是本SIP服务器支持的域名,如果是支持的域名,则会存储其AOR地址和Contact的具体的物理地址,并且此地址在一定超时设置内有效。这样,SIP注册服务器就获悉了SIP终端的AOR地址和Contact地址,它就会知道,如果其他SIP 终端呼叫时,SIP注册服务器知道如何路由这个呼叫,而且可以根据AOR地址解析到具体的SIP物理地址。
3、注册与定位服务
如果用户双方需要执行呼叫流程的话,呼叫流程还需要另外一半服务来协助完成呼叫。另外一半流程就是SIP服务中的定位服务(Location)。SIP中的定位服务和注册服务一样,它的功能概念仍然具有一定的抽象性。简单来说,它扮演一个服务角色,执行具体的流程,还执行某些功能。定位服务器可以独立存在,也可以和注册服务一起工作,存在于SIP服务器中。在一般比较小型的企业应用环境中,一般的定位服务和注册服务都部署在同一服务器。以下是一个简单的定位服务的示例图:
让我们看看SIP服务中的定位服务是如何工作的。如果双方进行呼叫的话,为了实现呼叫,呼叫方首先是执行一个定位服务,然后,定位服务器对被呼叫方进行查询,查询被呼叫方是否注册等状态,AOR地址等过程,最后才能实现真正的呼叫。这里,为了简单说明定位服务的功能流程,这里介绍的仅是一个简单的定位服务的处理流程,没有涉及其他的服务支持,比如重转发服务等。
根据以上图例介绍,这里的定位服务处理流程中,我们的定位服务,代理服务器和注册服务器都部署在同一服务器中。具体的定位服务大概经过以下几个步骤:
- 呼叫方通过AOR 地址呼叫对端,首先需要对SIP服务器的定位服务器/注册服务器发起一个INVITE消息。
- 定位/注册服务器收到INVITE消息后,检查AOR地址,是否是本服务器所属的AOR地址domain(work.com)和用户名称。这里,实际上就是定位服务的作用。
- 如果是本定位服务器支持的地址,则执行注册表查询,完整查询AOR地址和用户Contact匹配。在复杂场景中,可以执行重定位服务,这里不再讨论。注册查询成功。
- 然后注册服务查询对应的Contact地址确认,在注册表中有一个可用的注册状态正常的Contact地址。
- 提取Contact地址,定位服务把正式呼叫的任务转给代理服务器来完成。代理服务器对被呼叫方发起INVITE时,修改这个URL地址,替换成被呼叫方的Contact地址,对被呼叫方的具体物理地址和端口进行INVITE请求。
4、注册超时处理
注册服务器需要对Contact的状态进行查询,确认其状态可用,表示其是在正常的注册状态。注册状态控制的主要参数就是Expires。这个参数控制着终端注册的状态情况。
一般默认的注册超时设置是3600秒。用户终端注册时携带了这个设置,这表示此用户在3600秒钟内的状态是存活的。但是,这里读者一定要注意,即使用户设置的是3600秒,如果终端不能在超时范围内不停对注册服务器发送超时刷新的消息,注册服务器可能会认为此终端已经不再注册状态。因为,在某个时间段,可能其他SIP终端需要对此终端进行呼叫,如果不能不停刷新定时器超时设置,注册服务器可能不能得到准确的状态信息,这样可能导致呼叫失败。因此,终端会不断对注册服务器进行消息发送,保持这个存活状态。例如,现在,SIP终端开始对注册服务器进行注册,一个小时后,超时后,注册信息从注册服务器移除。注册时,默认超时设置为3600秒。
系统只能让SIP终端自己在默认传输时间内不断对注册服务器发起重新注册的消息。这也是我们通常所说的注册周期的概念。终端需要在一个特定的周期内不断按照设定的间隔周期重新注册,以便对注册服务器保持一个存活状态。当然,这个周期的设置取决于终端设置,以及服务器端的设置,因为,周期长短会影响服务器端的执行性能,会直接影响服务器的执行状态。
如果终端想退出注册和关机的话,SIP终端退出注册时,它仍然对SIP服务器发送一个注册请求,只是这次的请求携带了一个超时设置为零的设置,而不是3600。用户可能点击终端界面的退出注册或者关机,终端会直接对注册服务器发送一个注册消息,但是携带Expires=0, 通知注册服务器删除注册记录信息。注册服务器收到的定时器超时设置的参数设置后,删除所有相关记录。
5、注册消息
注册消息中需要包含如下头域,Contact头域可选:
- Request-URI:这个头域指明了登记服务所指明的位置服务所在区域,比如sip:chicago.com,SIP URI部分中的userinfo和“@”符号不能出现在该头域。
- To:这个头域包含了被查询、增加、修改的address-of-record,该头域是包含用户名的,这个AOR必须是SIP URI或SIPS URI。
- From: 这个头域包含了提交注册信息的用户的AOR信息,一般这个值和To头域的值相同。
- Call-ID:UAC发给某个注册服务器的所有注册请求都应该具有相同的Call-ID,否则注册服务器可能出现注册失效导致的故障。
- Cseq:该值保证了REGISTER请求的正确顺序,相同Call-ID的请求,每发出一个请求消息,该值递增1。
- Contact:REGISTER请求可以有一个Contact头域,这个头域包含0个或者多个绑定地址的信息。
- 注册消息只允许串行处理,即上一个注册请求收到响应或者超时前,不允许发送新的注册请求(包含新的Contact字段的新注册请求,非重传)。
6、多Contact地址处理
如果在一个注册请求中包含多个Contact头域,说明用户想把这些Contact头域内容都和To头域指定的AOR地址绑定起来,这个列表可以用“q”参数来区分绑定关系的优先级,比如:
这个Q值在用户注册时就已经设定,再次说明,Q值最高的具有最高的被呼叫优先级,另外,一定要注意,Q值总是小数,注册消息可能如下:
Contact: 192.168.1.3:5060 ;q=0.3 Contact: 192.168.1.23:5060 ;q=0.5 ……
一个AOR 地址可以支持多个Contacts地址,但是支持了多个Contacts地址的话,定位处理的机制会直接影响到呼叫的流程。我们可以想象一下,其他用户如果呼叫这个用户时,有几个疑问需要大家考虑:
- 这些地址是如何被定位和管理?
- 如何保证呼叫被路由到一个正确的地址?
- 如何能够保证其他的SIP终端都能完成可靠性处理,并且完全拆线?
事实上,以上疑问都是通过注册和定位服务来处理的。其实,在处理多个Contacts呼叫时,定位服务通过两种不同的模式来处理呼叫:并行呼叫处理(parallel forking)和按序依次呼叫处理模式(Sequential forking)。笔者在以前的讨论中讨论过关于呼叫查询的问题,并且介绍了每个请求处理的具体流程,读者可以查阅具体流程。今天,我们从另外一个角度再次对定位服务的处理机制进行讨论。
首先,我们介绍一下什么是按序依次呼叫处理模式(Sequential forking)。按序呼叫处理的流程是,呼叫方对另外一方进行呼叫,因为被呼叫方带有多个Contacts地址,因此,首先,呼叫方需要对定位服务进行查询,定位服务器按照Q值优先级顺序进行查询,Q(0.1-1.0之间)值高的具有高优先级。定位服务器首先对其contact地址进行呼叫。如果Q值最高的没有接听,则继续对次级的Q值进行查询呼叫,依此类推。直到找到一个接听呼叫的终端SIP。
另外一种呼叫模式是并行呼叫处理(parallel forking)的机制,它的处理机制则相对比较简单。如果呼叫方对定位服务器发起一个INVITE呼叫以后,定位服务器会对所有Contacts地址同时发起INVITE呼叫。最快接听的终端对定位服务器返回200 OK,然后,定位服务器对呼叫方返回200 OK和双方直接发送ACK,而不经过定位服务器,双方呼叫正式确认。接下来,定位服务器则同时对其他没有接听呼叫的终端发送Cancel消息。这里需要特别注意,根据Cancel的消息处理流程,定位服务器会同时对其他终端发送Cancel消息,200 OK,487,和ACK。
7、下期预告
下次讲一下OPTIONS吧