service_code_enable_warmline
A feature access service code used by Subscriber to activate the warmline service. The User Agent SHALL support at least two service codes in this property.
This reflects that fact that in typical dial plans there are two equivalent ways to dial a given service code. Please note that this property is honored only with “enable_warmline”, if it is set to “Subscriber”.
这个是warmline的业务码
比如
我们一般有一些业务码 *55啊之类的 很多业务都有
就是说用户可以通过拨号来选择激活或者关闭这个功能
比如移动给你开了个业务 这个只能他给你开 但是你可以选择不用
比如你自己拨一个这样的业务码就可以了
这个业务码拨的时候也要符合拨号规则
就是他说的dialplan 不然就会认为是非法的拨号了 就是这个意思
如果有业务码业务 要配置特定的dialplan同时
我们目前支持至少两种业务码
就是说用户可以至少配置两个业务码
功能是一样的
比如配置一个*55 再配置一个*33
都是表示这个功能
osi_timer
This property represents the Open Switch Interval duration. If this value is set to 0, then the ONT shall start permanent signal treatment immediately after timed release timer expires after BYE is received for an incoming/outgoing call. If it is non-zero, then after timed release timer expires, the ONT shall remove the loop current for the specified time and then it shall start permanent signaling treatment.
Session Timer机制分析
功能介绍
会话初始化协议（SIP）并没有为所建立的会话定义存活机制。尽管用户代理可以通过会话特定的机制判断会话是否超时，但是代理服务器却做不到这点。如此一来，代理服务器有时会无法判断会话是否还是活动的。例如，当一个用户代理在会话结束时发送BYE消息失败，或者由于网络问题BYE消息丢失，代理服务器将不会知道会话已经结束。在这种情况下，代理服务器将保持呼叫的状态并且无法知道呼叫状态信息何时失效。 为了解决这个问题，RFC4028为SIP会话定义了一种存活机制。用户代理周期性的发送re-INVITE或UPDATE请求用来保持会话的活动。会话更新请求的间隔通过其定义的协商机制决定。如果在间隔内没有收到会话更新请求，该会话被认为已经终止。用户代理会发送一个BYE消息，代理服务器则将该呼叫的所移除。
工作原理 UAC通过发送一个INVITE消息发起流程,这个消息包括一个带有可选标签“timer”的Supported头字段，用来表明支持Session Timer功能。该请求通过代理服务器传递，所经过的任一个代理服务器都可以依据他们的兴趣建立会话定时器。每个代理服务器都可以在请求中插入一个Session-Expires头字段和一个Min-SE头字段（前提是请求中还没有这些字段），或者修改上述已存在头字段的值。 Min-SE头字段为会话更新间隔建立了下限，也就是处理这条请求消息的SIP代理的最快会 话刷新率。这个头字段的目的是防止怀有恶意的代理服务器设置任意短的更新间隔以致它的邻居代理负荷超载。处理请求的每个代理服务器可以提高这个下限（实际上就是提高刷新的周期），但是不能降低下限。 Session-Expires头字段为会话更新间隔建立了上限，也就是任何一个代理服务器在处理一个请求之后必须为这个会话保持状态的时间周期。任何服务于该请求的代理可以降低这个值，但必须大于Min-SE头字段指定的值。 如果Session-Expires的间隔太小（小于代理服务器要维护的Min-SE头字段的值），那么代理服务器将拒绝这个请求并返回一个422响应。该响应包含一个Min-SE头字段表明它所支持的最小会话间隔。UAC再次尝试发送请求，这次请求中包含了Min-SE头字段，头字段等于先前接收到的所有422响应中最大的Min-SE头字段。这样一来，最小定时器就能满足所经过的所有代理服务器的约束条件。 在几次INVITE/422消息的反复传送后，请求最终到达UAS。UAS可以调整会话间隔的值就好像它自己也是一个代理服务器。之后，它将这个最终的会话间隔发入2xx响应的Session-Expires头字段。Session-Expires头字段还包含一个“refresher”参数用来表示更新的执行者（是当前的UAC还是UAS）。当2xx响应沿代理服务器链返回时，任何代理服务器可以观察这个最终的会话间隔但不能修改它。
通过响应中的Session-Expires头字段，UAC和UAS都知道会话定时器是活动的，它何时终止以及谁在更新会话。在终止前的某个时刻，当前活动的更新者生成一个会话更新请求，可以是一个re-INVITE或者UPDATE请求。如果更新者始终得不到这个会话更新请求的响应，它就会发送一个BYE消息结束会话。同样，如果另一端在会话终止前始终收不到会话更新请求，它也会发送一个BYE消息结束会话。
相关参数
(1) Session-Expires头字段 Session-Expires头字段用于传达SIP会话的会话间隔。 该字段只包含在INVITE或UPDATE请求，也包含在INVITE或UPDATE消息的任何一个2xx响应中。当在已经协商确定Session-Expires值,那么该会话将在Session-Expires/2的时间进行会话更新,该更新方式可以是re-INVITE或者UPDATE的请求。
(2) Min-SE头字段 Min-SE头字段表示会话间隔的最小值，以秒为单位。当它被用在INVITE或UPDATE请求中时，用来表示该会话所要使用的会话间隔的最小值。当它出现在请求或响应中，它的值不能小于90秒。如果这个头字段没有被指定，就取它的缺省值90秒。
（3）422回应代码 422响应代码出现在会话协商过程中，当Session-Expires的间隔太小（小于UAS所支持的Min-SE头字段的值）时，UAS将回应该代码要求UAC重新协商。
功能相关测试重点
（1）话机终端是否支持Session Timer功能，相关头字段信息： Supported: timer;
（2）会话更新的时间准确性，每次更新的时间间隔应为已经协商确定的Session-Expires值 一半；
（3）会话更新者的确定，可能是UAC也可能是UAS，但无论是哪方进行更新都应该有相 应的更新请求或者回应；
（4） 逻辑验证会话更新请求发送后，如果在Session-Expires/2的时间内没有得到对方的响 应（200 OK）信息，则发送BYE以拆掉当前会话；同样的，假如在规定时间内得不到更新者（Refresher）发送的会话更新请求信息，话机终端是否也会发送BYE；
（5）话机终端在更新过程中，如果更新者(Reresher)变动后，其会话的后续更新逻辑验证；
（6）不是所有的参与者都支持Session Timer情况下的会话更新逻辑验证。
Jitter
BCM JitterBuffer参数说明：
目前BCM驱动对JitterBuffer功能提供了五个设置参数（fixed、voiceMin、voiceMax、voiceTarget、dataTarget），其中前四个用于语音模式，最后一个用于数据模式。
五个值大体意思为：
Fixed：设置语音模式下JitterBuffer功能是静态模式还是动态模式，如果用于POS机环境，该值一定要设置为静态模式，因为POS机可能在语音模式下就有信号处理。如果是普通通话环境，一般设置为动态模式比较合理，DSP会根据实时网络抖动自动调整Activate Target阀值，以保证在语音质量和通话延时之间找到一个合理的平衡点。
voiceMin：仅在语音模式为动态时生效，在本地时钟与远端时钟有差异时才需要调整该值，通常该值设置为0（即认为本地时钟与远端时间几乎没有明显差异）。注意：这个值很多人都会误以为是动态调整的最小下限阀值，千万不要这样理解，待下面进行举例说明来加深理解该参数值的作用。
voiceMax：仅在语音模式为动态时生效，该值比较好理解，就是JitterBuffer的最大上限，超过该上限则产生缓冲区上溢，DSP会丢弃多余的数据。该值如果设置为0则表示使用DSP默认的最大值。该值主要用于在网络上产生异常大的延时，或者设备自身网络相关模块出现异常，导致JitterBuffer缓冲区在指定时间点，被填充大量数据包，进行一个界限防范。
voiceTarget：该值在语音模式为动态或静态时有不同的作用。
在语音模式为静态时，voiceMin和voiceMax将不启作用，该值用于标识JitterBuffer缓冲区最大上限。
当接收的数据包数量超过上限时，则删除多余数据。
当到达DSP采样周期，但缓冲区没有数据可处理时，DSP自动发送静音数据给用户侧。
当到达DSP采样周期，缓冲区有数据时，则从缓冲区取出一个数据包给DSP处理。
在语音模式为动态时，因为初期还没有数据包处理，所以DSP的Activate Target取该值为初始值，后期DSP会根据实时网络抖动自动调整Activate Target阀值，但Activate Target阀值自动调整范围为voiceTarget到voiceMax，注意这里是不是voiceTarget有点像缓冲区最小下限的意思，可以这样理解。Activate Target最关键的作用是在DSP到达采样周期后，会根据当前缓冲区中的数据是否大于或等于Activate Target值，而决定DSP如何处理，如果当前缓冲区中的数据还没有到达Activate Target阀值，则DSP自动发送静音数据给用户侧或重发上一语音数据，如果当前缓冲区中的数据到达了Activate Target阀值，则DSP从缓冲区中取出一个数据进行处理。Bcm建议初始target设置为0，好处是不需要我们分析网络实际抖动值来设置target，DSP可以根据当前网络抖动情况快速调整Target，但target设置为0的坏处是很容易产生缓冲区下溢，就会造成数据包被丢弃；但target设置为非0的值虽然上面问题不会产生，但因为设置target的值，将会造成在网络没有抖动的情况下，额外增加了点对点的媒体延时，即如果target设置为10，此时网络上没有抖动，但语音点对点通话一定会有额外的10ms延时存在。
dataTaget：仅用于数据模式，即DSP切换到数据模式时，该值将启作用，注意数据模式没有动态模式，只有静态模式，机制和语音静态模式相同，这里就不详细说明。
图例说明：（下面图例都是基于5ms的编码速率进行说明）
1、语音动态模式，初始target设置为0，缓冲区下溢，造成晚来的媒体包被丢弃。
这里大家要理解缓冲区下溢的概念，缓冲区下溢是指要要取缓冲区数据，但缓冲区是空的，此时就说缓冲区出现下溢。
这里DSP每5ms进行一样网络包采样，但在第10ms时才收到第1、第2个包，第1个包的时间戳与实际到达时间相差10ms，第2个包的时间戳与实际到达时间相差5ms，这两个包的差值都超过了当前Activate Target初始值0，所以DSP将这两个包做丢弃处理。如果此时设置target为30，则晚来的包实际时间与理论时间差值不会超过Activate Target初始值30，此时就不会被丢弃。
文档里不是提到Activate Target不是会自动增长吗？我的理解，因为初始通话，在没有数据包到达时，此时DSP
没办法算出网络抖动，因为网络抖动需要将两次包到达的实际时间与理论时间差值进行比较，所以此时DSP没办法
动态调整Activate Target。
2、语音动态模式，Activate Target自动调整。
在第0ms时，DSP收到了一个数据包，因为当前Activate Target为0，则将该包从缓冲区移到DSP处理队列进行处理。
在第5ms时，缓冲区产生下溢，重发第1个包到用户侧，同时根据之前的网络包到达时间，知道此时网络出现抖动，
DSP快速调整Activate Target值为20到30ms左右，与提高语音质量，之后如果网络没有抖动，则会慢慢地降低
Activate Target值，直到回退到target设置的值。
3、语音动态模式，初始target设置为20ms。
当前Activate Target初始值为20ms，则在缓冲区没有收集到20ms数据包之前，始终不将缓冲区数据移到DSP处理队列进行处理，直接到15ms时，DSP进行网络采样，才把第1个包移到DSP处理队列去处理。这里第30、35ms都不会出现缓冲区下溢，因为这期间缓冲区中一直有数据包存在。但这里有一点不足的就是，如果网络中没有抖动，则在两端会有额面的20ms延时产生。
4、语音动态模式，初始target设置为20ms。
在第0ms时，缓冲区已经存储了20ms的数据，达到了Activate Target值的界线，此时在DSP采样处理时，会把第1个包移到DSP处理队列，当在第5ms时，又来了一个数据包，此时又满足Activate Target值的界线，在DSP采样处理时，会把第2个包移到DSP处理队列，当在第10ms时，缓冲区只有15ms的数据，没有到达Activate Target值的界线，此时DSP采样处理时，将没有数据可供处理，则给用户侧发送静音包。
5、语音动态模式，设置了jitterMin，用于解决时钟抖动。
首先大家要清楚这里提到的时钟抖动概念，这里是说本端设备与网络侧远端设备的时钟差异，造成两端的时间有时候接近，有时候则不同。
例如，对端的时间是每分钟是60秒，但本端时间每分钟只相当于对端的59秒，这样本端每分钟就会比对端快1秒。
此时，缓冲区的数据会因为时钟抖动被本端快速处理完，导致产生缓冲区下溢。
我给大家用图例详细说一下这个问题原因，如下图，假如包速率为5ms，第1个包到达缓冲区，经过15ms后，第1个包需要交给DSP去处理，此时第1个包在缓冲区停留的时间即为15ms，因为本端与远端时钟基乎相同，所以缓冲区始终维持4个包，并且每个包在进到缓冲区，到离开缓冲区的时间都是15ms。
但当本端与远端产生时钟抖动时，本端侧的时钟比远端时钟快，将导致远端发包跟不上本端处理包，缓冲区队列包数量逐渐减少，最后引起缓冲区下溢，这里注意3号包，从到达缓冲区到离开缓冲区只有10ms的时间了，正常都是平均15ms，这里jitterMin的作用，就是限制一个包从到达缓冲区到离开缓冲的时间不能低于jitterMin值，如果低于jitterMin值，则DSP延缓该包在缓冲区停留时间，并向用户侧发送一个静音包。
pulse
所谓脉冲信号表现在平面坐标上就是一条有无数断点的曲线,也就是说在周期性的一些地方点的极限不存在,比如锯齿波,也有电脑里用到的数字电路的信号,0,1。脉冲信号,也就是像脉搏跳动这样的信号，相对于直流，断续的信号，如果用水流形容，直流就是把龙头一直开着淌水，脉冲就是不停的开关龙头形成水脉冲。
脉冲拨号
是一种时域处理方法，它用脉冲的个数来表示号码数字。脉冲拨号方式对脉冲的宽度、大小、间距、形状都有着严格的要求，如果由于线路的干扰或其他原因而使得这些参数发生了变化，则可能引起号码接收的错误。另一方面，由于每个脉冲都占有一定的时间(一般每个脉冲占用的时间为100ms)，而使得这种拨号方式比较慢。
Polarity Reverse
公用电话的一个计费信号。电话没提机时约50V左右，提机拨号时约10V左右，而当对方接听时，则变为-10V，这时公话计费卡等计费器开始计费。这是最好的计费方式。所以公话超市都要开通这一功能，没开通的要申请开通。其它：如回铃音计费等都会存在不准确性。有时电话短，没计费，有时电话嘟了一分多钟没人接切计了两分钟。（实测，实用）
反极性计费，是指在进入通话状态及结束通话时，通过A、B线上的极性反转，来通知计费终端（可以是计费器或IP超市等）计费起始点和计费终止点。受话摘机后极性反转（ANC），挂断后极性再反转，产生计费信号；反极性信号只能是主叫用户所在的交换机用户电路所发出的；可以用万用表测量到极性由正变负或反之摘机通话，用户端口提供一个电压，如果接了计费器的计费器开始计费，通话结束挂机，用户端口再提供一个翻转电压，计费器停止计费。
反极性顾名思义就是极性（电话线的A、B线正负极）反转了，至于什么时候反转：1：被叫摘机通话2：通话结束挂机。极性的反转会产生一个脉冲，这样记价器就能记录下用户通话的起始时间和终止时间完成计价，此功能多用于公用电话。
极性反转：是接听后才播放录音。可以识别是否是彩铃。（需要咨询运营商是否支持此功能和开通此功能）
增益
简单的说所谓电话卡的增益就是指当线路上的信号不够强，而其他电噪声有可能对通话造成影响时，增强有用信号的过程，一般可分为人工检测增益和自动控制增益。现代通信技术的发展，使得现有的产品几乎全为自动控制增益的产品，人工增益的几乎已经不在生产了。
DigitSendMode
1、DTMF（双音多频）定义：由高频音和低频音的两个正弦波合成表示数字按键(0~9 * # A B C D)。
2、SIP中检测DTMF数据的方法：SIPINFO、RFC2833、INBAND
1）SIPINFO
为带外检测方式，通过SIP信令通道传输DTMF数据。没有统一的实现标准，目前以Cisco SIPINFO为标准，通过SIPINFO包中的signal字段识别DTMF按键。注意当DTMF为“*”时不同的标准实现对应的signal=*或signal=10。SIPINFO的好处就是不影响RTP数据包的传输，但可能会造成不同步。
2）RFC2833
为带内检测方式，通过RTP传输，由特殊的rtpPayloadType即TeleponeEvent来标示RFC2833数据包。同一个DTMF按键通常会对应多个RTP包，这些RTP数据包的时间戳均相同，此可以作为识别同一个按键的判断依据，最后一包RTP数据包的end标志置1表示DTMF数据结束。另外，很多SIP UA 包括IAD都提供TeleponeEvent的设置功能如3CX Phone，Billion-IAD，ZTE-IAD等默认的TeleponeEvent都为101，但可以人为修改，这时要求在进行RFC2833 DTMF检测之前需事先获取SDP协商的TeleponeEvent参数。
3）INBAND
为带内检测方式，而且与普通的RTP语音包混在一起传送。在进行INBAND DTMF检测时唯一的办法就是提取RTP数据包进行频谱分析，经过频谱分析得到高频和低频的频率，然后查表得到对应的按键，进行频谱分析的算法一般为Goertzel，这种算法的实现也很简单，网上有很多可以下到，但建议采用定点算法，浮点算法效率很低。
在选择压缩比很高码率很低的codec，比如G.723.1和G.729A等，建议不要使用INBAND模式，因为INBAND DTMF数据在进行复杂编解码后会产生失真，造成DTMF检测发生偏差或失败。
另外，还特别需要注意的一点就是很多SIP UA中INBAND都是伴随着RFC2833和SIPINFO同时发生的，这时需要区别对待，最好选择RFC2833和SIPINFO。
Loop Current Feed Open（LCFO）
馈电，因为模拟话机普遍采用共电方式，即话机中送话器所需的直流工作电流由交换机提供，馈电电压一般为-48V。
FXS接电话机，rj11接口；
FXO接电话交换机出来的电话线，相当于自己是电话机，rj11接口；
E&M接电话交换机的模拟中继，4芯线。
在应用中可以简单理解为：
FXO为普通电话机接口，需要远程馈电；
FXS接口为PBX的内线分机接口，向远程馈电；
E&M为专用的一般用在PBX中继线接口。
CISCO提供的说法是：
FXO用于连接PSTN，二线（因为PSTN向用户馈电）
FXS用于连接POT普通电话机，二线（因为电话机需要FXS提供馈电信号）
E&M用于连接PBX，CISCO语音路由器可以设置二线或四线（因为PBX上可能配置E&M接口板）
prefer_early_media
1、早期媒体
无论是在PSTN还是在VoIP网络中，一个呼叫的最终目的让两个用户进行交谈（conversation）。这里我们将由用户之间的交谈所产生的媒体称为常规媒体（“regular media”）。
早期媒体（“early media”）是与常规媒体相比而言的。
通常，主叫用户发起呼叫后用户交谈并不会立即开始（甚至可能最终没有开始），等待时间一般是几秒到几十秒，这完全取决于被叫用户的何时应答。在被叫应答之前，主叫用户与网络之间也可以有媒体流产生，与常规媒体相区别，这种媒体被称为早期媒体。
最典型的早期媒体就是回铃音。其他形式的早期媒体还有排队提示等等。早期媒体通常都是单向的（网络>主叫），在SIP中也可能会有双向的早期媒体。
2、早期媒体的传送
要传送媒体首先要建立一个媒体会话（Session）。建立媒体会话实际上就是通过SDP offer/answer交换进行就会话的媒体参数进行协商的一个过程。在SIP中，媒体会话的建立过程通常首先伴随着一个SIP对话（Dialog）的建立过程，一般情况下，媒体会话和SIP对话是同时建立的（通过SIP 200或ACK消息携带SDP answer）。这种情况下，媒体会话直到被叫用户摘机以后才能建立起来，只能用户传送用户媒体，显然无法传送早期媒体。
要传送早期媒体，必须在SIP对话尚未完全建立之时，即所谓的SIP早期对话状态，完成媒体会话的建立。
怎样在早期对话状态建立媒体会话呢？SIP中支持两种做法。
这两种做法的关键不同在于：是否将传送早期媒体的会话与传送之后的通话媒体的会话明确地划分清楚，区别开来。具体到协议上看，两种做法都利用了200之前的 SIP消息，比如1xx-rel、PRACK、Update等等，来传送SDPoffer/answer， 但是这些SDP offer/answer在SIP消息中的标明类型和处理指示是不同的。
做法1没有明确区分出用于早期媒体的会话，实际上始终只有一个会话。具体到协议上看，用于建立（或修改）这个会话的SDP offer/answer 在SIP消息中的处理指示都是“Session”。
做法2专门建立一个用于传送早期媒体的会话，并称之为早期会话（“early-session”）。具体到协议上看，用于建立（或修改）早期会话的SDPoffer/answer SIP 消息中的处理指示是“early-session”。并且，在一个SIP消息中可以同时携带处理指示分别为“Session”和“early- session”的两个SDP消息，各自独立地用于早期会话的协商和正常会话的协商。
在做法1中，用同一个会话（在不同的时间段里）来传送早期媒体和通话媒体。在被叫摘机之前，这个会话可用于传送早期媒体，在被叫摘机之后，这个会话又用于传送通话媒体。倘若早期媒体和通话媒体的参数不同的话，需要重新进行媒体传输参数的协商，这需要一定的时间，可能会带来媒体删剪（media clipping）的问题。在做法2中，同时会存在两个会话，分别用于传送早期媒体和通话媒体，在被叫摘机之后，终端可以迅速从早期会话切换到正常会话，不会带来媒体删剪的问题。
根据它们的适用场景的不同，这两种做法分别被称为网关模式和应用服务器模式。
3、回铃音的产生
一个呼叫被发起之后，当被叫终端振铃时，主叫也会听到某种声音，提示正在等待被叫应答，这就是所谓回铃音。回铃音通常是某种标准的音频信号，也可能是被叫用户指定的某种特殊的声音文件，例如音乐等等。在PSTN中，回铃音通常是被叫的本地交换机产生，然后通过已建立的单向话路传送给主叫话机，由主叫话机播放给主叫。
在SIP网络中，被叫侧可以早期媒体的形式向主叫提供回铃音（如果被叫侧不提供回铃音，则主叫SIP终端会在本地产生回铃音）。究竟使用前面所述的两种做法的那一种来传送早期媒体，下面分别讨论。
3.1．网关模式
网关模式适用于被叫（即UAS）为一个SIP网关的情形。具体的可能的情况通常如下图所示：一个用户在SIP终端上呼叫一个PSTN用户，这个呼叫通过了一个SIP网关。就SIP呼叫而言，网关是被叫。
在这里，回铃音是由PSTN网产生的。但是在SIP域，SIP网关需要以早期媒体的形式将从PSTN网络收到的回铃音媒体传送给主叫SIP终端。
这种情况下，从SIP域来看，回铃音媒体流和之后的被叫媒体流的产生是同源的，都在SIP网关上。当被叫用户摘机时，回铃音媒体流自然地变成了用户媒体流，因此可以使用网关模式，而不会带来媒体删剪的问题。
信令流程如下图：
其中消息简单说明如下：
1) INVITE请求中含有SDP offer，其处置类型为“Session”。
网关收到INVITE后向PSTN发送IAM消息，然后在PCM话路上收到回铃音，同时在信令上收到ACM消息。
2) 183响应中含有SDP answer，其处置类型为“Session”。
此时，UAC与网关之间媒体会话建立，同时将回铃音在这个会话上传送给UAC。
3) UAC发送PRACK
4) 网关返回针对PRACK的200响应。
5) 被叫用户应答，网关收到ANM后向SIP UAC返回200 INVITE响应。同时到SIP UAC上的会话上的回铃音自动变成了从PSTN上收到的用户话音。主被叫用户开始双向通话
6) SIP UAC发送ACK。
3.2．应用服务器模式
应用服务器模式适用于被叫（即UAS）是一个应用服务器的情形。具体的可能的情况通常如上图所示：一个SIP用户希望由运营商网络（而非终端）来产生回铃音。运营商通常使用网络上的一个MRF资源提供回铃音，并且需要一个应用服务器其来控制回铃音的产生。
这种情况下，回铃音媒体流与之后的被叫媒体流分别在MRF与被叫SIP终端上产生，显然是不同的源。如果使用网关模式的话，将回铃音媒体切换为被叫媒体流必须在会话上进行媒体更改，媒体更改不能立即完成，这将会带来媒体删剪的问题。
使用应用服务器模式，则是同时建立了两个会话，将回铃音媒体切换为被叫媒体流可以通过将当前会话从早期会话切换到正常会话上即可，能够立即完成。
简单说明如下：
1) INVITE请求中携带一个SDP作为常规会话的offer
其Supported头域中包含一个选项标签“early-session”，表示主叫终端支持早期会话。
2) INVITE请求中携带之前收到的offer
3) 183响应中携带一个SDP作为常规会话的answer。
4) 183中含有两个SDP：
a) 一个是之前从被叫那里收到的，作为常规会话的answer；
此时常规会话被建立，但并没有媒体被传送。
b) 另一个作为要建立的早期会话的的offer.
5) PRACK中携带一个SDP，作为早期会话的answer
此时早期会话被建立，且有被早期媒体（回铃音）传送。
6) AS向被叫发送PRACK
7) 被叫向AS返回200 PRACK
8) AS向主叫返回200 PRACK
9) 被叫摘机，向AS发送200响应
10) AS向主叫发送200响应
此时常规会话上将会有媒体传送，主叫UA播放常规会话上的媒体。
4、关于目前多媒体彩铃的实现的简单说明
目前中国网通及中国移动的多媒体体彩铃业务的实现都主要采用了网关模式的实现方案（详细流程参见相关技术规范），原因是很多SIP终端都不支持“early-session”选项标签，无法使用应用服务器模式。
实际上，采用网关模式实现彩铃会导致媒体删剪等一些问题，最终应该会逐步过渡到理想的方案 –应用服务器模式。
Support100Rel Require100Rel
SIP定义了两种应答：临时（provisional)和最终（final）。
最终应答传送的是请求处理的结果，是可靠性的（reliably）。 而临时应答传送的是处理过程的信息，由RFC3261是非可靠的。
但是由现在的情况看来，特别是与PSTN交互过程中发现：临时应答也应该是可靠的。
RFC3262定义了一种SIP可选的扩展方法——PRACK（provisional ack），用于支持临时应答的可靠性。它的实现机制如下：
借鉴了INVITE请求的2**应答的可靠性机制：通过构造新的事务来重发ACK来确认接收到了2**应答，这种可靠性是端点到端点（end-to-end）的。对于1**（除100外）的应答，使用PRACK来终止该应答的重发。PRACK是对临时应答而言，不同于ACK，是一种跟BYE一样的正常SIP消息。所以它的可靠性是点到点（hop-by-hop）的，且具有应答。
每个临时响应都有一个顺序号，在于RSeq头域中。而PRACK消息包括了RAck头域，指示回应的临时相应的顺序号，且不具有积累效果。
UAS行为
如果请求INVITE的头域Supported中包括选项100rel，UAS可能发送可靠性临时响应；如果请求INVITE的头域Require中包括选项100rel，UAS必须发送可靠性临时响应，否则发送420 (Bad Extension)且Unsupported头域中包括选项100rel。
但是，如果请求中不满足以上任一情况，则不能支持可靠临时相应。
UAS需要发送可靠临时相应原因：
多种原因。其中之一为根据RFC3261,如果UAS需要一段时间来处理请求，UAS需要发送临时相应消息给Proxies来“延时（extention）”，因为Proxy一般只保留请求上下文3分钟，所以为了避免丢失消息，常需要1分钟重发一次。而使用可靠临时相应只需2分半钟重发一次。
可靠临时响应的构建：
只需在RFC3261的基础上进行一些补充：必须包括Require头域（包括100rel选项）和RSeq头域（值为1到2**32-1，是对话中是唯一的）。
PRACK和临时响应的匹配：
PRACK首先必须和临时相应在同一个对话之中，RAck中的方法、CSeq-num和response-num分别对应于临时响应CSeq中的方法、CSeq中的序号和RSeq的序号。
如果接受到的PRACK无法找到相匹配的临时相应，则回应481；否则回应2**，并停止该临时相应的重发。
如果在64*T1时间内没有接收到PRACK，则UAS回应5**。
在第一个可靠响应得到回应，才可以发送第二个可靠相应。对于同一个请求，第二个可靠相应的RSeq比第一个大1。
UAS可以在可靠临时响应未收到PRACK情况下发送最终应答，除了以下情况：最终响应为2**且其中一个临时相应中有媒体描述。如果最终响应已经发送，则临时相应的重发和新的临时消息发送都不能进行。
UAC行为
如果需要可靠临时应答，则在INVITE请求的Require头域中包含100rel选项，而其他方法中的Require中不能包含该选项；如果将可靠临时应答的需求的决定权交给UAS，则应在INVITE的头域Supported中包含100rel选项。
当头域Require中包含100rel的临时消息到来时，且临时消息非100，说明临时消息是可靠的。UAC接下来在对话中建立PRACK请求，跟其它在对话中建立的非INVITE请求一样，UAC不应在接收到重发的可靠临时应答时重发PRACK，即使重发不会引起协议错误。
一个临时应答到来时，如果dialog ID、CSeq、和RSeq跟之前的一样时，该应答视为重发，该应答必须被丢弃。所以，UAC需要记录RSeq值直到最终应答的到来。
如果新的一个临时应答到来时，需要判断RSeq是否比之前的值大。如果不是的话，则不能回应PRACK,可以丢弃该临时应答或缓存起来以等待没有到来的老的临时应答。
如果在最终应答到来之后收到临时应答，可以回应或直接丢弃。
注：
1）RFC3262中不支持除INVITE外其它方法的可靠性临时响应，除非是能建立对话的扩展方法。
2）UAS不能发送可靠的100临时相应。因为100响应一般是hop-by-hop的，即消息的可靠性在于hop的两端之间，而不在于端到端之间；而这里实现的可靠性是端到端之间的，即接受消息初始发送和最终接受方，能满足消息真正交互成功。但是PRACK的可靠性又是hop-by-hop的，即PRACK方法的消息交互依靠的是hop之间的确认。
SIP 中的Dialog，call，session 和 transaction
Messages(消息) 消息是在服务器和客户端之间交换的独立文本, 有两种类型的消息,分别是请求(Requests)和响应(Responses).
Transaction(事务) 事务发生于客户端和服务器端之间,包含从客户端发出请求给服务器,到服务器响应给客户端的最终消息(non-1xx message)之间的所有消息. 如果请求是一个"Invite"消息,并且最终的响应是一个non-2xx消息,那么该事务包含一个"Ack"响应消息.如果服务器的响应是一个2xx消息,那么,随后的ACK是一个单独的事务.
A sip transaction consists ofa single request and any responses to that request, which includes zero or moreprovisional responses and one or more final responses.The branch parametervalue in the VIA header is used to identify the transaction created by thatrequest
Dialog(对话)对话是两个UAs(user agent) 之间持续一段时间的端到端(peer-to-peer)的SIP 关系. 一个对话由一个Call-ID,一个local tag 和 一个remote tag来标识.对话过去也叫做 "call leg".dialog的建立是收到UAS的响应（To tag）时开始建立的。收到180响应时建立dialog叫做早期对话（early dialog）,收到2XX的应答开始才是真正的dialog建立。
A dialog represents apeer-to-peer SIP relationship between two user agents that persists for sometime, as a call-leg.It is identified at each UA with a dialog ID, whichconsists of a Call-ID, From tag and To tag. We can call a dialog is establishedwhen three values are all generated
Session(会话)
session 是媒体交换之后才建立的。具体而言就是通过offer/answer方式交换sdp的媒体。 session的建立可以使INVITE-200 也可以是200-ACK。这要看媒体的交换发生的时间。具体来说，INVITE 中的消息体用sdp语言来描述自己可处理的媒体类型，200OK中 带回UAS端可处理的媒体类型。这个时候媒体交换就算是完成了。也就是session建立起来了。
In the SDP specification, amultimedia session is a set of multimedia senders and receivers and the datastreams flowing from senders to receivers. A session is defined by theSDP user name, session id, network type, address type, and address elements inthe origin field.
A session can have multiple RTP sessions corresponding to the UDP ports definein the line of the SDP.
Call(呼叫) ：一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。一个 SIP 呼叫用全局唯一呼叫标识（CALL_ID）来识别。因此，如果一个用户被不同的人邀请参加同一个多点会议，每个邀请都有一个唯一的呼叫。
注: Dialog和Session都翻译成了会话,但两者显然不同.
下面的示意图清晰的显示了它们之间的关系
(RINGING 是 1xx 响应, OK是 2xx 响应)
caller呼叫callee的号码来建立一系列的对话(Dialogs),这些对话组成了一个呼叫(Call).
1.对话和事务处于信令层，而会话处于媒体传输层。SIP使用SDP来通知传输层（RTP）来创建、增加、移除和修改会话。
2.一般来说，在会议应用中SIP可以通过请求来让另一方加入已有会话中。在这种情况下，新的对话会被创建。
3.对话是end-point对end-point的关系，即真实的通信双方，
而transaction 是hopby hop的关系，即路由过程中交互的双方。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
呼叫（call）： 呼叫是一个非正式的术语，用来表示一个多媒体会话，用Call-ID来标识；不论两方通话还是在多方通话中，在每个UA中是使用同一个Call-ID；
事务(transaction)： 请求（UAC）+最终响应（相邻的UAS），SIP基于事务。所谓相邻就是说transaction存在于相邻的SIP实体，而不是存在于两个UA之间。CSeq标识。一个事务中包含一个请求消息、0个或多个临时响应消息、1个或多个最终响应消息（2xx~6xx）。SIP是事务性的协议。事务的区分通过Via字段栈顶的Branch的值来确定，这是由于对于请求消息每经过一个有事务状态的Proxy的时候，该Proxy需要为这个事务创建一个服务器端事务和一个客户端事务，并且将自己的URI添加到Via的栈顶，并生成一个GlobalID做为Branch的值，以此值来表示一个与之相对应的事务。SIP在事务层面定义了状态机和定时器来实现重传。
下图是一个回复200 OK的成功的INVITE事务：是不是INVITE事务区别在于 UAC需要为每个INVITE最终请求（2xx～6xx）生成ACK响应，而其他的请求消息（INFO,OPTION,etc）则不必如此。因为INVITE的地位比较重要，所以需要这样一个三次握手的机制来保证会话的双方都能够确保事务的完整性，这一点和TCP连接建立的三次握手比较像。
注意在上图这两个UA中，每一个代理服务器都将自己的地址加入返回的ACK的Via头域中，而非成功的transaction则不会加入，见RFC 3261 (p.24)。CSeq头域的值必须与INVITE相同，并且CSeq的方法必须是ACK。中间响应消息 1xx 的使用则是为了节省网络开销设计的，一旦 UC 收到任何一个中间响应消息，则 UC 必须停止消息重发定时器，不再从发这个请求消息，反之则直到收到最终响应消息或重发定时器超时。一旦客户端UAC的事务在Calling状态收到任何中间响应消息1xx，事务则自动切换到Processing状态，停止请求消息的重发。并且需要将中间响应消息传送给TU事务用户。在呼叫业务中，TU以及上层应用可以根据中间响应消息在用户界面上提示用户。一旦事务切换到Processing状态，任何其他中间响应消息也都要传送给TU。
而非INVITE事务则如下：
当UAC发出非INVITE请求时，它就会在事务管理子层上开启定时器F（TCP）或者是E（UDP），确保超时的时候进行重传。这适用于除了 ACK请求外的其他非INVITE请求。每次超时重传时E的时间都被翻倍，直到最大的4秒。而F超时时，UAC就会认为是Timeout，这个事务将被删除。
对话(dialog/leg）： 代表着两个SIP UA之间持续一段时间的端到端的联系（如：一段通话）。也就说仅仅存在于端到端的信令关系。当一个UAS发出对于INVITE（或者REFER）的非失败最终响应<=>200OK（BYE），则Dialog建立，同时这也是session的开始。UA和SIP代理服务器之间不会有对话。在SIP中呼叫中包含一个或多个Dialog（这仅仅存在于多方通话中）。Dialog终结于任意一端发出 BYE。Early Dialog可以通过UAC发出的CANCEL进行终结，更确切的说，所有早期对话在接收到非2XX最终响应时就被终结了。 Call-ID-value、To、From进行标识。Forking时体现明显。
在这个Forking的例子中，这个用户注册了三个设备，在用户被呼叫时，INVITE的Contact头域就被转换为三个INVITE发往三个设备。后边的q指的是优先级，q越小，优先级越高。其中的SIP注册服务器相当于一个Forking代理，尽管这个实体接收到两个ACK，但是除了这些ACK外，它与主叫方的信令交互都是属于一个transaction的，而与被叫方则分别建立了Transaction。另外，被叫方收到的两个ACK由分别建立了Transaction。注意Device3返回了488这样的非成功响应，SIP注册服务器（Forking代理服务器）没有将该响应发回主叫方，这是SIP代理一个重要的特征，SIP代理还能自行发出Request:CANCEL消息。
UAS对话层接收到一个新的对话请求INVITE消息后，在建立会话的响应消息2xx中，将请求消息里面的所有Route-Record字段拷贝到2xx消息中，并且UAS的对话层必须添加一个Contact字段使得对话中后续的响应（INVITE在2xx响应的情况下也包括ACK消息）、请求消息可以直接和本UA联系。当UAC收到UAS的INVITE的2xx响应消息后，如果2xx中不包含任何Route-Record字段的，则UAC可以选择直接发送ACK到Contact中地址&端口。
会话(session)： 多方用户的媒体关系，在对话的控制下建立。
下图是Early dialog、Session、Dialog、Transaction等的在一个UA-UA的呼叫中的体现：
在这个例子中，通过INVITE事务而成功建立起来的dialog必须有一个ACK进行回应，这是第二个transaction的开始，尽管ACK并没有回复，但是由于新的 branch-value被填入，所以这个ACK代表了一个新的Transaction的开始。注意，此时 transaction number(CSeq) 并没有根据INVITE而增加--也就是说若收到的最终响应不是2XX（是3XX--6XX），则该transaction中包含ACK，若最终响应是2XX，则ACK属于一个新的transaction(此处存疑，国外有资料将其视为一个新的transaction，但是RFC3261中的意思却是ACK不属于INVITETransaction，也不创建新的Transaction，但会重新计算Transaction参数--branchID)。早期对话是UAS以一个1XX响应作为回应时建立的。这样做的好处是在UAC可能在早期对话中发出诸如UPDATE这样的SIP请求。
DigitMap
一、什么是DigitMap？
DigitMap即数图，是驻留在终端内的拨号规则，用于检测和报告终端接收的拨号事件。采用DigitMap主要目的是提高终端发送被叫号码的效率，即当用户所拨的被叫号码符合DigitMap所定义的拨号规则之一时，终端将被叫号码用一个消息集中发送。DigitMap的格式在H.248协议或MGCP协议有严格定义，它由系列代表一定含义的字符串组成，只要所收到拨号序列与其中的一串字符匹配就表示号码已被收齐。
二、SIP用户接入DigitMap如何配置？
SIP协议用户接入时（如E8-C用户等），DigitMap是直接定义在E8-C等终端上，无法通过SS上或IMS的AGCF上配置下发（协议没有规定）；还可以通过ITMS远程下发，或者直接登录终端的WEB界面来配置。终端上的DigitMap被修改且应用后，终端语音部分会自动重启，需要5～20秒左右才会恢复正常语音通信。
三、DigitMap的语法（即所涉及字符的含义）
3.1 DigitMap所支持的字符
DigitMap可以由字符串和字符串列表来定义。DigitMap字符包括数字和字母，目前数图所包含的字符有“+#*-.0123456789ABCDTX[]|EFTSL”，不同厂家的终端或核心网所支持的字符也有一定的差异。以下是各个字符所代表的含义：（表1）
字符 含义 字符 含义
+ 表示+86中的+前缀，用于特殊能够直接送出带+前缀的拨号串 . 将之前的一个结构匹配0或多次，即代表将.之前的拨号事件重复0次或多次，与符号.匹配的定时器应是S
*#0-9A-D 分别代表具体的摁键E 代表*按键
- 两个数字之间用“-”相隔，匹配两者之间的所有数字 F 代表#按键
| 用于多个子规则的分隔符 T 对于匹配x.T规则的拨号，启动T定时器
X（或x） 通配符，表示0-9的数字摁键 S 短定时器
[] 一个或多个DTMF符号组成，前后需要用一对“[”、“]”括起来 L 长定时器
表1
3.2 DigitMap定义的相关约束
①[ ]要前后匹配、[ ]中间不能为空、[ ]中不能有‘|’、‘.’。②‘-’须处于两个数字之间，且后面的数字大于前面数字。整个表达式要处于[ ]中。③‘.’不能跟在‘L’、‘S’、‘T’后面。‘.’、‘L’、‘S’、‘T’不能为匹配子方案的第一个字符。
四、SIP协议DigitMap的匹配方式
4.1 SIP协议DigitMap的匹配方式
SIP协议数图的匹配方式有最小匹配和最大匹配两种模式。①最小匹配是指如果当前用户的拨号串已经完全匹配DigitMap中的任何一条子规则，终端就会发送INVITE送号。若当前用户的拨号串同时匹配两个字符串，会优先匹配更简配置的那个子规则。②最大匹配是指如果当前用户的拨号串已经完全匹配DigitMap中的一条子规则，同时又部分匹配其他一条或者多条子规则，则启动定时器；之后如果用户没有继续拨号，且定时器超时，终端就会直接送号；如果用户有继续拨号，若号码与较长的子规则匹配，终端上报与较长数图方案匹配的号码。
4.2 SIP协议DigitMap匹配方式的配置建议
对于现网要求用户拨完号就立即送号、以减少呼叫接续延时的情况，SIP协议DigitMap应配为最小匹配，这样既可保证有明确长度的子规则匹配后直接上报，又可以将x.T直接做一个子规则，匹配那些未知号段或位长不等位的号码（在短定时器超时后上报）。如果配置为最大匹配，要删除DigitMap中的x.T，同时还要提供完整的精细数图，日后如果有新增字冠还需对DigitMap进行维护，会带来很大的维护工作量、同时还会对用户的使用造成一定影响。
五、E8-C终端数图的定义原则和方案
5.1 E8-C终端数图的定义原则
（1）因大部分厂家所支持的最大子规则数是100个，本次在制定E8-C数图时子规则数要控制在100个以内。（2）为实现大部分拨号场景下客户拨号结束后都能立即送号，在定义数图时，对手机（本地和长途）、本地固话、长途固话、部分常用或电信主要业务特服的数图都尽量做到精确化匹配，每类呼叫场景数图精确化配置的具体原则如下第2点说明。（3）在定义本地固话数图时，需特别关注一下本地固话字冠所对应的号头是否有夹杂这一些特殊应用的号码，特别是那些位长比本地固话位长还要长的特殊字冠都需要单独配置数图，否则客户拨打这类号码会出现号码送不全的现象；如果夹杂的特殊应用的号码的位长比本地固话位长短，就不需要做特殊定义。（4）在定义长途固话数图时，对于某个区号段有存在7位和8位号码并存的情况，需对7位和8位的数图同时做精确化分析。如果只对8位做精确化分析、而7位做更简匹配分析，那8位数图就不起作用。（5）补充业务相关操作采用模糊匹配方式，才能保证覆盖所有补充业务操作场景。（6）因各厂家所支持的定时器不一样，最终确定各厂家使用大写T作为定时器。各终端厂家要将T定时器出厂默认配置为5秒。（7）为了适配各类用户的拨号都尽可能的立即上报，E8-C终端的数图要区分普通用户、加密的IC卡用户和CENTREX用户三类用户。对于CENTREX用户还要区分出群字冠和群内短号长度，否则拨号会有5秒的延时。（8）为了让用户在拨号结束后加拨#实现快速拨号、同时兼容各个厂家对加拨#作为快速拨号的结束符的处理机制的不同，各厂家统一用xx.#来实现该功能。（9）各厂家E8-C终端出厂默认采用x.T|x.#|*xx*xx*x.#|*.x.*.x.#数图。同时DigitMap的匹配方式出厂都要默认配置为最小匹配。用户在开户时，ITMS要根据用户的类型下发不同的数图给终端。 5.2 普通用户数图的定义说明
（1）补充业务相关操作数图说明
[*#][*#0-9][0-9*].#|#[09#]
[*#][*#0-9][0-9*].#----表示第一位是*或#，第二位是*或#或0～9十个数字中的任何一个，第三位是*或0～9十个数字中的任何一个，第四之后可以是*或0～9十个数字中的任何一个字符，最后一位以#结尾。
（2）长途固话数图说明
a）只对长途7位或8位的固定电话的数图进行细化分析，后续如果有哪些地方做7位升8位的工作，E8-C数图中长途字冠数图也要配套做修改。b）对于长途的一些常用特服，因数图的容量有效，无法做细化配置，用户如果有投诉拨号接续有延时，可引导用户加拨#。c）国际长途已经包含在x.T中，所以不再单独列做一个00xxx.T的数图。d）因数图匹配模式为最小匹配方式，要对省外每个本地网7位和8位数图做细化分析，现已确定以下长途区号打头的固话都是8位，除此之外其他本地网的固话都是7位010xxxxxxxx|02xxxxxxxxx|0[346-9]xxxxxxxxx|0311xxxxxxxx|037[179]xxxxxxxx|04[15]1xxxxxxxx|043[12]xxxxxxxx|051[0-9]xxxxxxxx|052[37]xxxxxxxx|053[12]xxxxxxxx|057[1345679]xxxxxxxx|0591xxxxxxxx|059[2346789]xxxxxxx|0731xxxxxxxx|075[457]xxxxxxxx|076[09]xxxxxxxx|0898xxxxxxxx。
（3）长途固话数图说明
01[3458]xxxxxxxxx|1[3458]xxxxxxxxx--长途手机和本地手机都是精确匹配。
（4）本地固话数图说明
泉州本地固话都是8位，且20、40、60、70、80打头的号码都是一些特服、没作为固定电话的号码，所以本地固话的数图就定义为[2-8][1-9]xxxxxx，虽然泉州2～8打头的字冠中除了大部分作为固定电话外，还有个别字冠用于一些特殊的用途（例如5644、24343等），但这些特殊字冠的位长都小于8位，所以不需要做特殊的定义。
（5）部分本地特服精确匹配数图说明
100xx|11[049]|11887[12]|11888|118114|1118[35]|12[02]|12[13]xx|16[0-2]|163xx|168xxxxx|200|201[01]|201[89]8|2013[01]|20170|2014[89]xxxxxxxxxxxxxx|[48]00xxxxxxx|955xx|96168xxxxx
其他精确匹配的特服字冠的确定是依据以下原则：固定位长（即最大位和最小位是等位长）、客户较常用的字冠、电信的主要业务特服且字冠相对连续的字冠。
（6）其他数图说明
a）x.T----表示那些无法精确匹配的号码都是用这个通配规则来匹配。b）xx.#----用于作为中兴、贝尔和贝曼厂家加拨#实现快速拨号。
DTMF
双音多频：dual-tone multifrequency
双音多频 DTMF（Dual Tone Multi Frequency），双音多频，由高频群和低频群组成，高低频群各包含4个频率。一个高频信号和一个低频信号叠加组成一个组合信号，代表一个数字。DTMF信号有16个编码。利用DTMF信令可选择呼叫相应的对讲机。
1基本释义
双音多频信号（DTMF），电话系统中电话机与交换机之间的一种用户信令，通常用于发送被叫号码。
在使用双音多频信号之前，电话系统中使用一连串的断续脉冲来传送被叫号码，称为脉冲拨号。脉冲拨号需要电信局中的操作员手工完成长途接续(早期方法，很老很古董)。
双音多频信号是贝尔实验室发明的，其目的是为了自动完成长途呼叫。
双音多频的拨号键盘是4×4的矩阵，每一行代表一个低频，每一列代表一个高频。每按一个键就发送一个高频和低频的正弦信号组合，比如'1'相当于697和1209赫兹(Hz)。交换机可以解码这些频率组合并确定所对应的按键。
2工程术语
双音多频(DTMF)是由贝尔实验室开发的信令方式，通过承载语音的模拟电话线传送电话拨号信息。每个数字利用两个不同频率突发模式的正弦波编码，选择双音方式是由于它能够可靠地将拨号信息从语音中区分出来。一般情况下，声音信号很难造成对DTMF接收器的错误触发。DTMF是“TouchTone”(早期AT&T的商标)的基础, 替代机械式拨号转盘的按键。
3网络释义
双音多频
双音多频（DTMF）是一种在话音信道用音调来表示数字的方法，它可以用来在模拟话音信道传输信令，因此在通信中有广泛的应用。
双音频
所谓双音频（DTMF）是指用一频率较高的信号与一频率较低的信号叠加，“4”是770HZ和1209HZ信号的叠加，“3”是697HZ和1477HZ信号的叠加等。
功能
在附加功能上，这款显卡支持双音多频功能（DTMF），支持短信息服务功能附加服务来电显示，还支持电话簿管理。
信号
(1)指令信号传输方式 考虑到本系统的信号传输是加载到电力系统上进行传输的,所以本系统采用双音多频信号(DTMF)作为传输信号,DTMF是由一组低音频信号和一组高音频信号以一定方式的组合构成,每组音频信号各有4个音频信号,而每种组合有一个低音频信号和一个高音频信号.
4相关短语
DTMF Dialer 双音多频拨号
DTMF PAUSE 传送DTMF码时之暂停时间
DTMF O 双音频输出脚
DTMF STORE 储存DTMF码
DTMF DoubleToneMultiFrequency双音多频
DTMF Package 双音多频包
Start DTMF 启动双音多频
DTMF DigitalTrunkModules 数字主体模块
DTMF HOLD 每输入DTMF码时
5信号产生
DTMF编码器基于两个二阶数字正弦波振荡器，一个用于产生行频，一个用于产生列频。向DSP装入相应的系数和初始条件，就可以只用两个振荡器产生所需的八个音频信号。典型的DTMF信号频率范围是700~1700Hz，选取8000Hz作为采样频率，即可满足Nyquist条件。DTMF双音频信号由两个二阶数字正弦振荡器产生，一个用来产生行音频信号，另一个产生列音频信号。
6产生流程
CCITT规定每秒最多按10个键，即每个键时隙最短为100MS，其中音频实际持续时间至少为45MS，不大于55MS，时隙的其他时间内保持静默，因此按键产生双音频信号时，相继的两个信号间隔一段时间；解码器利用这个时间识别出双音频信号，并转换成对应的数字信息，而且要识别出间隙信息。因此流程包含音频任务和静默任务，前者是产生双音频采样值，后者产生静默样值，每个任务结束时，要重置定时器和下一个任务。其中静默任务还要加上一个任务：从数字缓冲区取出数字并解包。解包就是将数字映射为对应的行列音频特性，装载指针指向振荡器特征表对应的正确位置。两个任务轮流执行。由CCITT（国际电报电话咨询委员会）的规定，数字之间必须有适当长度的静音，因此编码器有两个任务，其一是音频信号任务，产生双音样本，其二是静音任务，产生静音样本。每个任务结束后，启动下一个任务前（音频信号任务或静音任务），都必须复位决定其持续时间的定时器变量。在静音任务结束后，DSP从数字缓存中调出下一个数字，判决该数字。信号所对应的行频和列频信号，并根据不同频率确定其初始化参数。
7识别
DTMF信号包含两组音频信号，解码器的任务是通过数学变换把它从时域转化到频域，然后得出对应的数字信息。由于芯片处理的是数字信号，所以必须把输入信号数字化，再用DSP芯片处理。频率检测时，检测出DTMF信号的基波及二次谐波，DTMF信号只在基波上有较高的能量，而话音信号则是在基波上叠加有较强的二次谐波，检测二次谐波的作用是用来区分DTMF信号与语言和音乐信号。
8特性
DTMF是由低频组（fb）和高频组（fa）两组频率信号构成，每个数字信号由低频组和高频组的任意一个叠加而成。根据CCITT的建议，DTMF的编译码定义可用下式表示 f(t)=A_{a}sin(2f_{a}t)+A_{b}sin(2f_{b}t)式中两项分别表示低、高音频的值，Ab和Aa分别表示低音群合高音群的样值量化基线，而且两者幅值比为K=Ab/Aa(0.7<K<0.9)。同时规定，对应于DTMF编译码中的标称频率在发送时，DTMF信号的频率偏差不应当超过1.5%，每位数字的信号极限时长应该大于40ms，而接收设备对2%的偏差应能可靠地接收，对30ms~40ms时长的信号可以正常地接收。
与单音编码不同，DTMF信号是采用8中取2的方式，从高低两个音组中各取一个音频复合而成来代表0-9十个号码和其他功能码，再加上这8个音频信号的各频率间不存在谐波关系，大大减少了虚假信号的干扰，因而DTMF信号工作可靠性特别是抗干扰能力很强。
9应用
DTMF信号即双音频信号，最先用于程控电话交换系统来代替号盘脉冲信号，主叫用户摘机按键拨号后，电话号码所对应的DTMF信号通过电话线传到程控交换机中的DTMF接受电路，交换机中的微机识别被叫电话号码后，接通主被叫用户实现双方通话。
DTMF信号还用于自动控制系统，如果把DTMF的发送电路用于主控系统，接收电路用于被控系统，就可以方便地组成有线或无线通信系统，其通道数视需要而定，16通道以内每通道只需编一位号码即可，若需要更多通道，则可像电话号码编号一样编为两位或两位以上的号码。
DTMF信号还被用于部分型号的车载导航终端，用于远程下发目的地坐标信息。
10编解码器
在编码时将击键或数字信息转换成双音信号并发送，解码时在收到的DTMF信号中检测击键或数字信息的存在性。一个DTMF信号由两个频率的音频信号叠加构成。这两个音频信号的频率来自两组预分配的频率组：行频组或列频组。每一对这样的音频信号唯一表示一个数字或符号。电话机中通常有16个按键，其中有10个数字键0～9和6个功能键*、#、A、B、C、D。由于按照组合原理，一般应有8种不同的单音频信号。因此可采用的频率也有8种，故称之为多频，又因它采用分别从高低频中任意抽出1种进行组合来进行编码，所以又称之为“8中取2”的编码技术。根据CCITT的建议，国际上采用的多种频率为697Hz、770Hz、852Hz、941Hz、1209Hz、1336Hz、1477Hz和1633Hz等8种。用这8种频率可形成16种不同的组合，从而代表16种不同的数字或功能键.
voip sip audio code音讯编解码标准
音讯编解码标准
G.711：以64Kbps通道作3KHz频宽的电话品质音讯讯号处理，运用在48~64Kbps窄频带。
G.722：以64Kbps通道作7.5KHz频宽的高品质音讯讯号的处理。
G.728：以16Kbps通道作近似电话品质的音讯讯号的处理。
G.729：是一个8Kbps语音编码的新标准。
PCMU(G.711U)
类型：Audio
制定者：ITU-T
所需频宽：64Kbps(90.4)
特性：PCMU和PCMA都能提供较好的语音品质，但是它们佔用的频宽较高，需要64kbps。
优点：语音品质优
缺点：佔用的频宽较高
应用领域：voip
版税方式：Free
备注：PCMU and PCMA都能够达到CD音质，但是它们消耗的频宽也最多(64kbps)。如果网路频宽比较低，可以选用低比特速率的编码方法，如G.723或G.729，这两种编码的方法也能达到传统长途电话的音质，但是需要很少的频宽（G723需要5.3/6.3kbps，G729需要8kbps）。如果频宽足够并且需要更好的语音品质，就使用PCMU 和 PCMA，甚至可以使用宽频的编码方法G722(64kbps)，这可以提供有高保真度的音质。
PCMA(G.711A)
类型：Audio
制定者：ITU-T
所需频宽：64Kbps(90.4)
特性：PCMU和PCMA都能提供较好的语音品质，但是它们佔用的频宽较高，需要64kbps。
优点：语音品质优
缺点：佔用的频宽较高
应用领域：voip
版税方式：Free
备注：PCMU and PCMA都能够达到CD音质，但是它们消耗的频宽也最多(64kbps)。如果网路频宽比较低，可以选用低比特速率的编码方法，如G.723或G.729，这两种编码的方法也能达到传统长途电话的音质，但是需要很少的频宽（G723需要5.3/6.3kbps，G729需要8kbps）。如果频宽足够并且需要更好的语音品质，就使用PCMU 和 PCMA，甚至可以使用宽频的编码方法G722(64kbps)，这可以提供有高保真度的音质。
ADPCM(自我调整差分PCM)
类型：Audio
制定者：ITU-T
所需频宽：32Kbps
特性：ADPCM(adaptivedifference pulse code modulation)综合了APCM的自我调整特性和DPCM系统的差分特性，是一种性能比较好的波形编码。它的核心想法是：
一利用自我调整的思想改变量化阶的大小，即使用小的量化阶(step-size)去编码小的差值，使用大的量化阶去编码大的差值；
二使用过去的样本值估算下一个输入样本的预测值，使实际样本值和预测值之间的差值总是最小。
优点：演算法複杂度低，压缩比小（CD音质>400kbps），编解码延时最短（相对其它技术）
缺点：声音品质一般
应用领域：voip
版税方式：Free
备注：ADPCM (ADPCM AdaptiveDifferential Pulse Code Modulation), 是一种针对 16bit (或者更高?) 声音波形资料的一种失真压缩演算法, 它将声音流中每次採样的 16bit 资料以 4bit 存储, 所以压缩比 1:4. 而压缩/解压缩演算法非常的简单, 所以是一种低空间消耗,高品质声音获得的好途径。
G.711
类型：Audio
制定者：ITU-T
所需频宽：64Kbps
特性：演算法複杂度小，音质一般
优点：演算法複杂度低，压缩比小（CD音质>400kbps），编解码延时最短（相对其它技术）
缺点：佔用的频宽较高
应用领域：voip
版税方式：Free
备注：70年代CCITT公佈的G.711 64kb/s脉衝码调制PCM。
G.721
类型：Audio
制定者：ITU-T
所需频宽：32Kbps
特性：相对于PCMA和PCMU，其压缩比较高，可以提供2：1的压缩比。
优点：压缩比大
缺点：声音品质一般
应用领域：voip
版税方式：Free
备注：子带ADPCM（SB-ADPCM）技术。G.721标准是一个代码转换系统。它使用ADPCM转换技术，实现64 kb/s A律或μ律PCM速率和32 kb/s速率之间的相互转换。
G.722
类型：Audio
制定者：ITU-T
所需频宽：64Kbps
特性：G722能提供高保真的语音品质
优点：音质好
缺点：频宽要求高
应用领域：voip
版税方式：Free 或商业付费
备注：子带ADPCM（SB-ADPCM）技术
G.723(低码率语音编码演算法)
类型：Audio
制定者：ITU-T
所需频宽：5.3Kbps/6.3Kbps
特性：语音品质接近良，频宽要求低，高效实现，便于多路扩展，可利用C5402片内16kRAM实现53coder。达到ITU-TG723要求的语音品质，性能稳定。可用于IP电话语音信源编码或高效语音压缩存储。
优点：码率低，频宽要求较小。并达到ITU-TG723要求的语音品质，性能稳定。
缺点：声音品质一般
应用领域：voip
版税方式：Free 或商业付费
备注：G.723语音编码器是一种用于多媒体通信，编码速率为5.3kbits/s和6.3kbit/s的双码率编码方案。G.723标准是国际电信联盟（ITU）制定的多媒体通信标准中的一个组成部分，可以应用于IP电话等系统中。其中，5.3kbits/s码率编码器採用多脉衝最大似然量化技术（MP－MLQ），6.3kbits/s码率编码器採用代数码激励线性预测技术。
G.723.1(双速率语音编码演算法)
类型：Audio
制定者：ITU-T
所需频宽：5.3Kbps(22.9)
特性：能够对音乐和其他音讯信号进行压缩和解压缩，但它对语音信号来说是最优的。G.723.1採用了执行不连续传输的静音压缩，这就意味著在静音期间的位元流中加入了人为的杂讯。除了预留频宽之外，这种技术使发信机的数据机保持连续工作，并且避免了载波信号的时通时断。
优点：码率低，频宽要求较小。并达到ITU-TG723要求的语音品质，性能稳定,避免了载波信号的时通时断。
缺点：语音品质一般
应用领域：voip
版税方式：Free 或商业付费
备注：G.723.1演算法是 ITU-T建议的应用于低速率多媒体服务中语音或其它音讯信号的压缩演算法，其目标应用系统包括H.323、H.324等多媒体通信系统 。目前该演算法已成为IP电话系统中的必选演算法之一。
G.728
类型：Audio
制定者：ITU-T
所需频宽：16Kbps/8Kbps
特性：用于IP电话、卫星通信、语音存储等多个领域。G.728是一种低时延编码器，但它比其它的编码器都複杂，这是因为在编码器中必须重複做50阶LPC分析。G.728还採用了自我调整后置滤波器来提高其性能。
优点：后向自我调整，採用自我调整后置滤波器来提高其性能
缺点：比其它的编码器都複杂
应用领域：voip
版税方式：Free 或商业付费
备注：G.728 16kb/s短延时码本激励线性预测编码（LD-CELP）。1996年ITU公佈了G.728 8kb/s的CS－ACELP演算法，可以用于IP电话、卫星通信、语音存储等多个领域。16 kbps G.728低时延码激励线性预测。
G.728是低比特线性预测合成分析编码器（G.729和G.723.1）和后向ADPCM编码器的混合体。G.728是LD-CELP编码器，它一次只处理5个样点。对于低速率（56~128 kbps）的整合式服务数位网路（ISDN）可视电话，G.728是一种建议採用的语音编码器。由于其后向自我调整特性，因此G.728是一种低时延编码器，但它比其它的编码器都複杂，这是因为在编码器中必须重複做50阶LPC分析。G.728还採用了自我调整后置滤波器来提高其性能。
G.729
类型：Audio
制定者：ITU-T
所需频宽：8Kbps
特性：在良好的通道条件下要达到长话品质，在有随机比特误码、发生帧丢失和多次转接等情况下要有很好的稳健性等。这种语音压缩演算法可以应用在很广泛的领域中，包括ＩＰ电话、无线通讯、数位卫星系统和数位专用线路。
G.729演算法採用“共轭结构代数码本激励线性预测编码方案”（CS-ACELP）演算法。这种演算法综合了波形编码和参数编码的优点，以自我调整预测编码技术为基础，採用了向量量化、合成分析和感觉加权等技术。
G.729编码器是为低时延应用设计的，它的帧长只有10ms，处理时延也是10ms，再加上5ms的前视，这就使得G.729产生的点到点的时延为25ms，位元速率为8 kbps。
优点：语音品质良，应用领域很广泛，採用了向量量化、合成分析和感觉加权，提供了对帧丢失和分组丢失的隐藏处理机制
缺点：在处理随机比特错误方面性能不好。
应用领域：voip
版税方式：Free 或商业付费
备注：国际电信联盟（ITU-T）于1995年11月正式通过了G.729。 ITU-T建议G.729也被称作“共轭结构代数码本激励线性预测编码方案”(CS-ACELP)，它是当前较新的一种语音压缩标准。G.729是由美国、法国、日本和加拿大的几家著名国际电信实体联合开发的。
G.729A
类型：Audio
制定者：ITU-T
所需频宽：8Kbps(34.4)
特性：複杂性较G.729低，性能较G.729差。
优点：语音品质良，降低了计算的複杂度以便于即时实现，提供了对帧丢失和分组丢失的隐藏处理机制
缺点：性能较G.729差
应用领域：voip
版税方式：Free 或商业付费
备注：96年ITU-T又制定了G.729的简化方案G.729A，主要降低了计算的複杂度以便于即时实现，因此目前使用的都是G.729A。
In general, these featureapplied to both IPCentrex/Host PBX and Personal services in IMS.
Call forwarding
CFA-> Call forwardingalways （无条件前转
CFB-> Call forwarding busy （遇忙前转
CFNA-> Call forwarding no answer （无应答前转
CFS-> Call forwardingselective （有选择前转
CFBOP-> Call forwarding based on presence（我猜是根据用户前转吧
Call transfer
CTTWC -> Call transfer with three-wayconsultation
CTTPC -> Call transfer withthird-party consultation
CTNC-> Call transfer with no consultation
call forwarding: 呼叫前转, 可以包括遇忙前转, 无应答前转, 不可及前转, 关机前转等. 至于转接到甚么号码,是用户自己可以在终端或者自服务portal上面设置的.
call transfer: 呼叫转接, 有盲转和询问转接等.---这个场景是, 你是一跨国公司大老板, 坐在办公室里面, 这时候你有一小学同学A打电话给你, 你的秘书接到了这个电话:
1, 如果她说, A,你等等, 我给你转过去, 这时候你的老板桌上面电话响了,你pickup, 直接和A就通话了------这就是盲转.
2, 如果秘书说, A, 你等等, 然后A听一段等待音, 你桌面电话响了, 你pick up, 秘书问你, 你有一小学同学A给你电话, 你这时候选择接听或者不接听----这就是询问转接.
也就是说前转有有通知的和无通知的。