深圳市宝安区华美居

0086-18665301040

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

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

Spiral: spiral是一种“螺旋式”处理方式,它是一个SIP请求,返回到代理,然后,代理再把这个请求前转到其他的终端,但是处理的流程不同,也导致和初始的URL不同。通常情况下,螺旋式处理方式表示请求中的Request-URI和上一次抵达的请求中的URL是不同的。注意,螺旋式的处理流程处理不是一个错误条件,它和loop(回环完全不同)。典型的使用场景是呼叫前转的处理。A用户呼叫 joe@example.com。这里的example.com是一个代理,它会前转到用户Joe的电脑终端,接下来,joe会把这个呼叫前转继续前转到bob@example.com。这里的请求其实又回到了同一代理example.com。但是,这种处理方式不是loop环境。因为,这里的请求发生了变化,它触发了不同的呼叫,这里的URL是bob@example.com,不是joe@example.com。所以,它的处理是有效的处理流程,被认为是一种螺旋式的处理。而在loop中,它的处理流程和Request-URI是保持不变的,代理重复处理同样的流程,因此导致触发错误条件。

其他说明:

这里,笔者提醒读者,笔者总感觉以上英文概念Spiral翻译成螺旋式处理流程也不一定准确,但是笔者一时间没有找到更加准确的中文用词。

另外,IPPBX可以比较轻松实现类似呼叫转移到功能,在一些SBC的设备中也特别支持了SIP spiral 呼叫。

Stateful Proxy: 状态代理是一个逻辑实体,它按照规范中请求处理的流程保持用户端和服务器端之间的事务状态机的处理状态,也就是所谓的事务状态代理。状态代理的执行在Section 16做了进一步的说明。状态代理(事务)和呼叫状态代理是不同的。

Stateless Proxy: 无状态代理是一个逻辑实体,它不会保持用户端和服务器端之间的事务状态机。无状态代理前转从下游收到的每个请求,前转从上游收到的每一个响应。

Strict Routing: 如果代理被称为严格代理表示这个代理遵守RFC 2543的路由处理规则,和一些比较早的RFC 版本规范。当Router 头出现时,那个规范会引起代理破坏 Request-URI的内容。严格路由的流程不在本规范中使用,本规范支持松散路由的处理。因此,执行严格路由的代理也被称之为严格路由器。

Target Refresh Request: 目标刷新请求是在一个dialog中发送,这个请求可以修改dialog中的远端目标。

Transaction User (TU): TU是处理协议层,它存在于事务层。TU(事务用户)包括UAC core,UAS core和proxy core。

Upstream: 它表示在事务中的前转消息方向,针对的是从用户代理服务器端返回到用户代理客户端的响应流程。

URL-encoded: 一个通过规范的RFC 2396, Section 2.4[5]解码的字符串。

User Agent Client (UAC):用户代理客户端是一个逻辑实体,它创建了一个新的请求,并且使用客户端事务状态机发送请求。UAC的角色是仅维持那个事务的时长。换句话说,UAC是一款软件,它发起一个请求,它以UAC的方式工作。如果它后续收到一个请求,它以用户代理服务器的方式来处理事务流程。

UAC Core: 一系列UAC的请求处理功能,它在事务层和传输层以上。

User Agent Server (UAS): 用户代理服务器是一个逻辑实体,它对SIP请求生成一个响应。响应接受,拒绝或转发请求。它的角色是仅维持事务时长。换句话说,它是一款软件来响应请求,它以UAS的方式工作。如果在后续状态中收到一个请求,它以用户代理客户端的方式来处理事务流程。

UAS Core: 一系列UAS的请求处理功能,它在事务层和传输层以上。

User Agent (UA): UA是一个逻辑实体,它能以用户代理客户端或者用户代理服务器端的方式工作。

UAC和UAS的角色,代理和转发服务器都是基于事务对事务的基础上定义的。例如,用户代理以UAC的方式发起一个呼叫时,发送请求时,它的工作方式是UAC;当从被呼叫方收到一个BYE请求时,它的工作方式是UAS。同样的道理,同样的软件,它可以以代理服务器的方式工作来处理请求,也可以以转发服务器的方式工作来处理下一个请求。

代理,定位服务器和注册服务器都是逻辑实体。在部署时,它们可以集成为一个单一的应用服务器。

7

SIP Messages

SIP 是基于文本的协议,使用的是UTF-8 charset (RFC 2279[7])。

一个SIP消息可以是从客户端到服务器端的请求消息,也可以是服务器端到客户端的响应消息。

虽然它们的语法规范和字符设置不同,请求 (section 7.1) 和响应 (section 7.2) 消息都使用RFC 2822[3]的基本格式来处理。(SIP支持RFC 2822无效的头)。两种类型的消息由一个起始行,一个或者多个头,一个表示头结束的空行和一个可选的消息体表示。

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

起始行,每个消息头和空行都必须以换行符结尾。注意,即使没有消息体,空行也要显示。

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

除了上面字符的不同以外,很多SIP消息和SIP头语法都是遵守HTTP/1.1的语法。于其在这里重复语法和语义的定义,这里,我们建议使用HTTP/1.1规范的[HX.Y] 的部分作为参考 (RFC 2616[8])。

但是,SIP不是HTTP的拓展。

参考资料:

https://www.fftelecoms.org/app/uploads/2018/03/Version-2-1-interface-SIP-FFT-pour-interconnexion-voix_clean.pdf

https://docs.oracle.com/cd/E21764_01/doc.1111/e13807/overview.htm#OWLDG97410

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

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

关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享

Asterisk freepbx 中文官方论坛:http://bbs.freepbx.cn/forum.php

Asterisk freepbx技术文档: www.freepbx.org.cn

融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com

Asterisk/FreePBX中国合作伙伴,官方qq技术分享群(3000千人):589995817

联系电话-18665301040
客服-3
客服-2
客服-1