您当前的位置是:  首页 > 技术 > 企业通信 > 文摘 >
当前位置:首页 > 技术 > 企业通信 > 文摘 > SIP协议与应用场景技术分享笔记-卷1-rfc3261-8

SIP协议与应用场景技术分享笔记-卷1-rfc3261-8

2019-09-23 09:17:05   作者:james.zhu    来源:Asterisk开源派   评论:0  点击:


  SIP协议与应用场景技术分享笔记-卷1-rfc3261-8
  以下是关于RFC3261的规范说明,内容比较枯燥。具体理解这些概念,建议读者参考笔者以前的文章:
  一封信读懂SIP注册消息关键词
  To
  首先To头也是最重要设定了期望的请求逻辑,或者用户的address-of-record,或者是一个请求目标资源。这可能是或者不是最终请求接收方。To头可能包含一个SIP或者SIPSURL,但是,如果在其他所要求的场景中,它也可以使用其他的URLschemes (例如,tel URL (RFC 2806[9])。所有的SIP部署必须支持此SIPURI scheme。任何支持TLS部署的,必须也支持SIPS URI scheme。To头支持一个显示名称。
  UAC可以通过多种方式学习如何对一个特别的请求映射To头。通常情况下,用户建议通过人机界面输入To头,也许通过人工输入URL或从地址薄中选择其地址。很多情况下,用户没有输入完整的URL地址,而是输入一个数字字符串或者字母(例如,“Bob”)。这是UA的自定义的输入方式,用户自己解析这个输入结果。使用字符构建SIPURL的用户部分应用在UA期望名字可以被解析为一种域名格式,植入到SIPURL中的@符号前(例如,sip:bob@example.com)。使用字符构建SIPS的用户部分应用在用户希望通信在安全状态,名称可以被域名解析。右侧域名经常是请求者的主机名称,支持主机域处理出局的请求。对于某些功能来说非常有用,例如,“快速拨号功能”。快速拨号功能要求解析主机域名的用户部分内容。tel URL 可以使用在某些环境中,UA不需要设定域名,只是解析用户已输入的电话号码。更准确地说,每个请求通过的domain都会有这样的机会。举例,一个在机场的用户可能登录系统,通过一个outboundproxy发送请求。如果他输入号码是“411”的话(这个号码是美国当地号码查询系统),这个号码需要解析,然后通过在机场的 outbound proxy做进一步处理,而不是用户的主机domain处理。这种情况下,tel:411就是一个正确的选择路由。
  一个在dialog外面的请求不能包含一个To tag; 请求中的To来确认dialog的peer。因为没有创建dialog,因此也没有tag出现。
  关于To 头域的进一步介绍,请参阅Section 20.39。
  以下是一个有效的To 头域的示例:
  To:Carol
  From
  From 头指示初始请求的逻辑实体,可能是用户address-of-record地址。就像To头值一样,它包含一个URL地址和可选显示名称。它被SIP要素用来决定一个请求所需要的处理规则(例如,自动拒绝呼叫)。这是非常重要的规则处理,在一个正在运行的UA中,From头不能包含IP地址和这个主机的FQDN,因为它们都不是逻辑名称。
  From头支持一个显示名称。除了正确的语法以外,一个UAC应该使用这个显示名称"Anonymous",如果客户实体是隐藏状态,则是一个无实际意义的URL(例如,sip:thisis@anonymous.invalid)。
  通常情况下,在一个指定UA生成的请求中,其From头的值是由用户或者用户本地域名管理员预设临时值。如果一个指定的UA用来支持多个用户的话,它可能带有一个可切换到属性设置,这个属性设置文件包括一个URL,这个URL和其用户属性实体文件相对应。请求接收方能验证请求的发起方身份,以便确认它们在From报头的身份声明(Section 22规范了更多关于验证的机制设定)。
  From报头必须包含一个由UAC选择的新的“tag”参数。具体选择细节查看Section 19.3。
  更多关于From报头细节,参考Section 20.20。
  例如:
  • From:"Bob" ;tag=a48s
  • From:sip:+12125551212@phone2net.com;tag=887s
  • From:Anonymous ;tag=hyh8
  Call-ID
  Call-ID 头工作方式类似于一个唯一的标识符,它用来成组一系列的消息。在一个dialog处理过程中,任何一方UA发送的所有请求和响应都必须包含相同的Call-ID。每个UA注册中的Call-ID应该是相同的。
  在一个外部dialog由UAC创建的请求中,Call-ID头必须由UAC选择,在整个处理和时间段上,它可以作为一个全局的唯一标识,除非其他设定的methods处理流程修改它。所有SIPUA必须有其含义来确保这个它们生成的Call-ID头不会被其他UA不经意生成一个新的Call-ID。注意,当获取到请求时,对于某些失败响应处理时,这些失败响应针对此请求要求一个重新修正(例如,认证流程),这些获取到的请求不会认为是一个新的请求,因此,它们不需要一个新的Call-ID。
  具体细节规范请参考Section 8.1.3.5。
  规范推荐使用cryptographically random identifiers (RFC 1750[12])来生成Call-ID。部署格式可以使用此格式"localid@host"。Call-ID是大小写敏感的,可以进行一比特一比特的简单对比。
  使用cryptographicallyrandom identifiers提供了对会话的保护,防止被黑客篡改,同时也降低了唯一Call-ID的相似度冲突。
  对于请求来说,不能通过配置或者界面来提供Call-ID头选项选择。
  关于更多Call-ID头的说明,参考Section20.8。
  示例:
  Call-ID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
  
    
  关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享
  Asterisk freepbx技术文档: www.freepbx.org.cn
  融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com
  Asterisk/FreePBX中国合作伙伴,官方qq技术分享群(3000千人):589995817
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关热词搜索: SIP协议

上一篇:神经网络发展浅析

下一篇:最后一页

专题

CTI论坛会员企业