您当前的位置是:  首页 > 资讯 > 文章精选 >
  •  首页 > 资讯 > 文章精选 >

    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 <sip:carol@chicago.com>
      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" <sips:bob@biloxi.com> ;tag=a48s
  • From:sip:+12125551212@phone2net.com;tag=887s
  • From:Anonymous <sip:c8oqz84zk7z@privacy.org>;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协议

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

    下一篇:最后一页

    专题

    各大党政科技媒体争相报道亿联网络
    各大党政科技媒体...
    各大党政科技媒体争相报道亿联网络 [详细]
    2019中国客户体验创新大会
    2019中国客户体验...
      由CTI论坛主办的 将于2019年10月17日在深圳益田威...[详细]
    2019中国爱博体育赞助巴塞中心及企业通信大会
    2019中国爱博体育赞助巴塞中心...
     [详细]
    小i智慧学堂
    小i智慧学堂
      小i智慧学堂是一个AI应用人才培养与发展平台,致力...[详细]

    CTI论坛会员企业