IP电话、传真业务总体技术要求
前言
本标准对不同IP电话运营者之间的互通、IP电话的网络体系结构、协议、编号、网络性能等多方面内容作出了明确规定。
从国际标准化的符合程度和互通方面考虑，目前我国IP电话/传真网的建设应以ITU-T H. 323 建议为基础。本标准主要参照见H.323v2 随着V oIP技术的不断发展．需要对本标准进行补充和完善。
IP电话业务包括电话到电话、PC到电话、电话到PC和PC 和PC，本标准对电话到电话和PC到电话作了明确的规定，电话到PC的业务有待进一步研究，故仅对编号作了规定，PC到PC业务不属于本标准规定的范畴。
IP实时传真业务（简称IP传真）包括传真机到传真机、IAF（Internet Aware Fax）到传真机、传真机到IAF 和IAF到IAF 4种，目前只开放传真机到传真机的业务。
本标准为我国IP电话/传真网络的规划、设备研制、工程设计和运营维护提供技术依据。
本标准的附录A为标准的附录。
本标准由信息产业部电信研究院提出并归口。
本标准起草单位：信息产业部电信传输研究所
深圳市华为技术有限公司
上海贝尔有限公司
本标准主要起草人：蒋林涛叶冠华叶华陈忠杨昆沈群谢玮
1 范围
本标准规定了开展IP电话／传真业务的网络体系结构、协议、编号、计费、用户认证、地址解析、网络性能和不同运营者的IP电话之间的互通等要求。
本标准适用于国内IP电话/传真网络的规划、设备研制、工程设计和运营维护。
2 引用标准
下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。在标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。
ITU- T H.323：1998 用于提供不保证质量的业务本地网上的可视电话系统和终端设备
ITU- T H．225．0：1998用于不保证质量的业务本地网上的可视电话系统的媒体流的打包与同步
ITU-TH245：1998 多媒体通信的控制协议
RFC2138：1997 RADIUS协议
RFC2139：1997 RADIUS计费协议
ITU-T T.30：1998 文件传真在公用电话交换网上的传输规程
ITU- T T．38：1998 三类终端间通过IP网络的实时通信的规程
TU-T G．711：1988 话音频率的脉冲编码调制
ITU- T G729：1996 运用共轭结构代数码线形预测激励的8kbit/s语音编码
ITU-T G．728：1992 采用线形预测激励的低时延码在16kbit／s速率上的语音编码
ITU-T G.723.1:1996 以5.3kbit/s和6.3kbit/s 为速率的多媒体通信的双速语音编码器
3 定义
本标准采用下列定义：
IP电话（IP Telephony）：在IP网上传送的具有一定服务质量的语音业务。
IP实时传真业务（IP Fax）：在IP网上传送的具有一定服务质量的实时传真业务
网关（Gateway）：网关是IP电话网的接入设备，它位于电路交换网与IP网之间，为用户提供IP电话业务。
网守（Gatekeeper）:网守是提供地址解析和接入认证的设备。
RADIUS：网守与认证和计费中心之间授权（Authorization）、认证（Authentication）和计费（Accounting）的标准协议。
SNMP（Simple Network Management protocol）：是IP网络的网络管理的标准协议。
4 缩略语
本标准使用下列缩略语。
GW Gateway 网关
GK Gatekeeper 网守
IAF Internet Aware Fax 能直接连在IP网上的三类传真机
IFP InternetFacsimile Protocol IP传真协议
UDPTL UDP Transport Layer UDP传送层
RRQ Registration Request 注册请求
RCF Registration Confirm 注册确认
RRJ Registration Reject 拒绝注册
URQ Unregistration Request 注销请求
UCF Unregistration Confirm 注销确认
URJ Unregistration Reject 注销拒绝
ARQ Adrmission Request 接入请求
ACF Admission Confirm 接入确认
Am Adndssion Reject 接入拒绝
BRQ Bandwidth Request 带宽请求
BCF Bandwidth Confirm 带宽确认
BRJ Bandwidth Reject 带宽请求拒绝
DCF Dlsengase Confirm 退出确认
DRJ DisengageReject 退出拒绝
RRQ Disengage Request 退出请求
RIP Request in Progress 进展请求
IRQ InfoRequest 信息查询
IRR InfoRequest Response 信息查询响应
LACK InfoRequestAck 信息查询确认
INAK InfoRequestNak 信息查询否认
RAI Resource Availability Indication 资源可用性指示
RAC Resources Available Confirmation 资源可用性确认
TCS Tenminal Capacitv Set 终端能力集
TCS Terminal Capacity Set Acknowledge 终端能力集确认
TCSR Terminal Capacity Set Reject 终端能力集拒绝
OLC Open Logical Channel 打开逻辑通道
OLCA Open Logical Channel Acknowledge 打开逻辑通道确认
OLCR Open Logical Channel Reject 打开逻辑通道拒绝
CLC Close Logical Channel 关闭逻辑通道
CLCA Close Logical Channel Acknowledse 关闭逻辑确认
CLCR Close Logical Channel Reject 关闭逻辑通道拒绝
ESC End Session Command 结束会话命令
5 IP电话／传真业务
5．1 IP电话业务
根据IP电话的记帐方式，IP电话分为两种：记帐卡方式的IP电话和主叫号码方式的IP电话。
记帐卡方式IP电话允许用户在任何一部DTMF电话机、PC机或数字移动终端上进行电话呼叫，并把费用记在规定的帐号上。使用记帐卡方式的用户必须有一个唯一的个人卡号（Card Number）。用户使用本项业务时，按规定输入接入码、卡号和密码。当网络对输入的卡号和密码进行确认且向用户发出确认指示后，持卡用户可像正常通话一样拨打被叫用户号码进行呼叫。
主叫号码方式IP电话允许用户在任何一部已经申请该业务的电话机上进行电话呼叫，并根据主叫号码进行计费。使用主叫号码方式IP电话业务的用户必须提前到电信业务受理部门申请。用户使用该业务时可以按规定直接输入接入码和被叫用户的电话号码；也可以按规定直接输入接入码，当网络对主叫号码进行确认且向用户发出确认指示后，可像正常通话一样拨打被叫用户号码进行呼叫。
5．2 IP（实时）传真业务
根据业务的计费方式，IP传真业务分为两种：记帐卡方式的IP传真和主叫号码方式的IP传真。
记帐卡方式IP传真允许用户在任何一部G3传真机上进行传真呼叫，并把费用记在规定的帐号上。使用记帐卡方式的用户必须有一个唯一的个人卡号（Card Number）。用户使用本项业务时，按规定输入接入码、卡号和密码。当网络对输入的卡号和密码进行确认且向用户发出确认指示后，持卡用户可像正常传真通信一样拨打被叫传真号码进行通信。
主叫号码方式IP传真允许用户在任何一部已经申请该业务的传真机上进行传真呼叫，并根据主叫号码进行计费。使用主叫号码方式IP传真业务的用户必须提前到电信业务受理部门申请。用户使用该业务时可以按规定直接输入接入码和被叫用户的号码；也可以按规定输入接入码，当网络对主叫号码进行确认且向用户发出确认指示后，可像正常传真通信一样拨打被叫传真号码进行通信。
6 IP电话/传真网的网络体系结构及网络组织
6．1 概述
我国IP电话／传真网总体框架见图1，主要包括IP承载网络、IP电话网关、IP电话网络的管理设备（如网守、计费/认证中心等）和传统电路交换网的接入部分。
6．2 IP电话传真网的网络体系结构
IP电话／传真网采用两级体系结构，见图2，即顶级网守和一级网守。在业务量大的地区可根据需要再增加第三级结构，即二级网守。
其中顶级网守云可以包含多个顶级网守。顶级网守之间的连接、一级网守与顶级网守之间的连接以及不同运营者之间的连接由各运营者根据各自的情况自行确定其具体的连接方式。当IP电话运营者的网络规模不是很大时，顶级网守的功能可由其中一个一级网守完成。
6．2．1顶级网守的主要功能
顶级网守负责管理属于该运营者的所有一级网守，主要负责一级网守之间的地址解析；完成不同运营者IP电话/传真网之间的互通和地址交换；负责管理国际业务，即国际呼叫的建立与拆除均需经过顶级网守。
6．2．2一级网守的主要功能
一级网守主要负责管理该一级网守所管辖的全部二级网守间的地址解析工作。在两级网的情况下，二级网守的功能全部归入一级网守。
6．2．3二级网守的主要功能
二级网守所管辖范围称为一个区域，二级网守主要负责所属区域内用户的地址解析和认证，防止非法用户的接入和非法网关的登记；负责向所属网关提供路由信息，包括被叫网关的端口信息等；负责完成PC到电话业务的呼叫建立、释放和计费信息的采集。
6．3 IP电话/传真系统的参考模型
IP电话/传真系统的组成单元主要包括网关、网守、计费中心和结算中心。
参考点A：H.323终端或网关与最低级网守间的参考点，采用RAS协议，主要完成终端用户的地址解析和认证信
息的传送。
参考点B：H．323终端或网关与H．323终端或网关间的参考点，采用H．225和H．245协议，主要完成用户之间的呼叫建立、释放和语音流传送等功能。
参考点C：计费／认证中心之间的参考点，采用RADIUS协议，主要传送漫游用户的计费／认证信息。
参考点D：本级网守与上一级网守间的参考点，采用RAS协议，主要传送用户地址解析信息。
参考点E：网关与电路交换网间的参考点，可采用ISUP、TUP、DSSI以及中国1 号信令，完成至电路交换网的呼叫或接收来自电路交换网的呼叫。
参考点F：本级网守与本级计费/认证中心间的参考点，采用RADIUS协议，向计费／认证中心传送计费采集信息和认证信息。
参考点G：计费中心与结算中心间的参考点，传送结算信息。
参考点H：本级结算中心与上一级结算中心间的参考点，传送不同区域之间的结算信息。
参考点I：受理终端与计费/认证中心间的参考点，传送用户的注册、修改和注销等信息。
6．3 PSTN/ISDN侧的网络组织
原则上，我国IP电话业务应实现IP电话来、去话全覆盖，即未设置IP电话网关地区的用户能够接收来自IP电话网的呼叫，也能拨打IP电话，进行IP电话呼叫。
目前，IP电话/传真网应能够与现有的PSTN、ISDN和GSM互通，其接口信令优选NO．7 ISUP信令（信令点编码采用24位），在条件不具备的情况下也可采用中国1号或DSSI等其他信令。
6．3．1 PSTN/SDN至IP电话／传真网的网络组织
发端IP电话网关应与网关所在电话本地网内的PSTN/ISDN汇接局间设置直达电路，当某些端局的业务量相对比较大时，也可在端局和网关之间设置直达电路。当该本地网内存在多个汇接局时，可根据话务量大小的情况确定是否需要在所有汇接局与网关之间设置直达路由。
汇接局至网关的连接主要用于疏通网关所在本地网内用户发起的IP电话业务，同时也可以传送其他未设置IP电话网关的本地网用户通过长途电路和市话电路至该网关后所进行的IP电话业务。
终端长途局至网关的连接用于未设置网关的本地网通过长途网接至网关的IP电话业务的疏通。
当网关所在本地网的端局的业务量相对比较大时，可在该端局与网关之间设置直达路由，立即疏通端局的IP电话业务。
6．3．2 IP电话/传真网至PSTN/ISDN的网络组织
终端IP电话网关应与网关所在电话本地网内的PSTN/ISDN汇接局和终端长话局间设置直达电路，也可在端局和网关之间设置直达电路。当该本地网内存在多个汇接局时，可根据话务量大小的情况确定是否需要在所有汇接局与网关之间设置直达路由。
网关至发端长途局的连接的目的是完成IP电话来话全覆盖，传送至未设置网关的本地网用户的IP电话呼叫业务。
网关至汇接局的连接主要完成IP网至网关所在本地网的IP电话业务的疏通，也可以通过汇接局完成IP电话来话全覆盖的功能。
网关至端局的连接的目的是当至网关所在本地网的某个端局的IP电话业务量比较大时能够快速疏通业务，该连接方式也可以完成IP电话来话全覆盖功能。
IP电话网与PSTN/ISDN互通的网络组织涉及到IP电话运营者与PSIN/ISDN网络运营者之间的结算、网络组织、业务量的大小等问题，双方可根据实际情况选择相应的方式进行互通。
6．4 GSM侧的网络组织
从技术成熟度考虑，目前IP电话与GSM的互通采用通过GMSC的方式比较合适，今后能否采用其他互通方式有待进一步研究。IP电话与GSM互通的详细网络组织见图6，网关与网关所在本地网内的GMSC之间设置电路，从而保证来自GSM网的IP电话呼叫立即进入IP网，IP网至移动用户的呼叫立即进入GSM网。
6．5 IP电话国际业务的网络组织
为有效地管理我国IP电话国际业务，国际IP电话来话业务和去话业务（包括协议和信息流）均由顶级网守负责
管理，如认证、呼叫建立和释放等。详细网络组织见图7。开放IP电话国际业务有多种方案，如在国外新建网关、与其他国家合作，利用他国已经建立的IP电话网络开放国际业务、加入国际组织等，IP电话运营者可根据自己的实际情况进行选择。
7 编号
IP电话/传真的业务类型有4种方式：电话/传真到电话/传真、PC到电话/传真、电话/传真到PC和PC到PC。本标准重点考虑前三种方式的编号，本标准对于第四种方式不加讨论，它可以利用IP网的原有机制来完成寻址。7．1 IP电话业务接入码
根据信息产业部的相关规定，同时考虑到我国IP电话网合出现多个运营者，需要通过接入码区分不同的运营者，因此我国IP电话业务的接入码采用6位编码，具体格式规定如下：179X1、X2、X3。
其中X11X2 X3 可由各运营者向信息产业部申请，各IP电话业务运营者可根据自己业务开放情况，申请一个或多个X1X2 X3 。X1X2X3 可以区分不同运营者，也可以表示一个运营者内的多种业务。
7.2 普通电话／传真用户的编号
当被叫用户为普通电话用户或传真时，被叫用户号码的编号方式与现有电话网用户的编号方式相同，即E．164的编号方式。
7.3 PC用户的编号
有待进一步研究。
7.4 卡号
记帐卡方式的IP电话卡号的编号方式原则上可由IP电话运营者自己确定。本标准推荐以下编号方式。
我国IP电话记帐卡卡号的长度为18位，具体格式如下：
8986X1X2YZ1 Z2 Z3 Z4 Z5 Z6 Z7 Z8 Z9 Z10 Z11
89：电话业务标志。
86：中国国家代码。
X1 X2 ：发行机构识别码，以区别不同IP电话运营者。
Y：业务类别码。
Z1 ～Z11：用户个人帐号。其中，Z1～Z3 是地区识别码，具体分配方案由IP电话业务运营者决定。
7．5 拨号程序
7．5．1 记帐卡方式的电话到电话业务
记帐卡方式IP电话的拨号程序如下：
用户拨" 179X1 X2 X3 。
按照录音提示选择提示语言（至少应提供普通话和英文两种选择）。
按录音提示拨卡号。
技录音提示进行密码操作：
1）按提示要求输入自己的密码。
2) 按录音提示拨被叫用户号码。
7．5．2 主叫号码方式电话到电话业务
以：二次拨号为例，主叫号码方式电话到电话的拨号程序如下：
用户拨"179 X1 X2 X3".
按照录音提示选择提示语言（至少应提供普通话和英文两种选择）。
按录音提示拨被叫用户号码。
当主叫用户完成拨号等待被叫应答时，可听到让主叫用户等待的录音通知。
7．5．3 未设置网关地区的用户的拨号程序
以二次拨号为例，主叫号码方式电话到电话的拨号程序如下：
用户拨"0十长途区号十179X1 X2 X3 "。
按照录音提示选择提示语言（至少应提供普通话和英文两种选择）。
按录音提示拨被叫用户号码。
当主叫用户完成拨号等待被叫应答时，可听到让主叫用户等待的录音通知。
8 接入认证和地址解析
8．1 接入认证体系结构
IP电话的接入认证体系包括以下三个部分：网关（GW）、网守（GK）和RADIUS服务器。
参考点A：位于网关和二级网守之间，两者之间的认证过程采用RAS消息。
参考点I：位于二级网守和二级计费／认证中心之间，两者之间的认证过程采用RADIUS协议。
参考点J：位于二级计费／认证中心和一级计费／认证中心之间，两者采用RADIUS协议进行通信，解决不同二级网守之间的用户的漫游认证。
参考点K：位于一级计费/认证中心和一级计费/认证中心之间，两者采用RADIUS协议进行通信，解决不同一级网守所辖区域用户的漫游认证。
参考点L：位于一级计费/认证中心和其他运营者的一级计费/认证中心之间，两者采用RADIUS协议进行通信，解决跨运营者的用户的漫游认证。
参考点M：位于一级网守（若无二级网守）和一级计费/认证中心之间，两者采用RADIUS协议进行通信。
二级计费／认证中心只包含它对应的二级网守所辖区域的用户信息。一级计费／认证中心应包含一级网守所辖区域全部用户的信息，对于单个运营者来说，顶级网守不参与用户的认证过程，用户的漫游认证由一级计费/认证中心完成。对于不同运营者经营的IP电话网，用户漫游认证也是如此。
本标准暂不考虑国际用户的漫游认证。
8．2接入认证与授权流程
系统采用分散受理、集中管理的接入认证和授权管理体系。用户数据由各营业管理点录入，数据集中存放在计费/认证中心（RADIUS服务器）的数据库中，用户的接入认证由各自的网关向网守请求，网守向相连的计费／认证中心进行用户认证；对于卡号用户，计费/认证中心利用RADIUS协议进行漫游处理。
流程如下：
a) 网守收到网关或PC用户发来的"请求用户接入认证"（ARQ）消息，如果用户数据由计费中心控制，则利用"接入请求"（Access－Request）消息将用户主叫号码、被叫号码发送到RADIUS服务器，如果是卡号用户，还需要将用户卡号，密码等发送到RADIUS服务器。
b）计费中心进行用户认证，如通过，向网守回送"接入认可"（Access－Accept）消息；否则，回送"接入拒绝"（Access －Reject）消息。对于卡号用户，在RADIUS服务器无法进行接入认证的时候，还需要向其他RADIUS服务器进行漫游处理。
c）处理同b）。
d）对于有实时卡断要求的卡号用户，如果被叫号码已经给定，还需要将用户最大通话时长放在"接入认可"消息中。
e）网守收到RADIUS服务器来的"接入认可"或"接入拒绝"消息后，向网关／PC用户发送ACF或ARJ消息。8．3 地址解析流程
在网关可以有地址解析表的缓冲区，电话／传真到电话／传真的地址解析可以在网关中完成。如果不能完成，则向网守请求地址解析，并将新的地址解析数据存放在缓冲区里。
对于卡号用户，网关可以一次性收集用户帐号、密码、被叫号码等，利用ARQ一次性进行接入认证和地址解析，也可以分两次进行。图10所示为地址解析流程。
对于PC用户，本标准要求PC一次性将用户信息、被叫号码利用ARQ发送到网守。
9 计费与结算
9．1 计费与结算系统的体系结构
IP电话/传真网的计费和结算系统由结算中心、计费中心、计费采集点组成。单个运营者的IP电话/传真网的结算
中心体系原则上采用两级结构，即顶级结算中心、一级结算中心。根据不同地区的业务需要也可增设二级结算中心。
注：因本节与认证过程无关，故将计费/认证中心简称为计费中心。
顶级结算中心的功能如下：
a) 接受一级结算中心递交的漫游用户资费清单，并转至其开户地所在一级结算中心。
b）负责所辖各一级结算中心之间的资费结算。
c）完成与传统电话网的结算。
d) 完成不同运营者之间的结算。
e) 负责整网的国际业务结算。
一级结算中心的功能如下：
a) 一级结算中心负责对所辖各二级结算中心之间的资费结算。
b）将在本区发生的异地开户的漫游用户资费清单交至顶级结算中心。
c）接收顶级结算中心转交的其他一级结算中心提供的本地区开户的漫游用户的异地资费清单。
d）完成与传统电话网的结算。
二级结算中心完成与传统电话网的结算。
二级计费中心的功能如下：
a) 二级计费中心接收计费采集点发送的用户使用IP电话的起始和终止时间等计费信息，生成原始记录数据CDR （Call Detail Record），根据费率生成帐单。
b）对于记帐卡用户，二级计费中心还要根据用户帐号，将余额转换成用户使用IP电话的最大时长并送到计费采集点，以免用户透支。
c）二级计费中心还要负责将本区发生的漫游用户资费清单交至二级结算中心。
一级计费中心的功能同二级计费中心的功能。
计费采集点的功能如下：
在"电话到电话"的情况下计费采集点设在发端网关，在" PC到电话"的情况下，计费采集点设在相应的网守。
计费采集点（主叫）负责采集用户使用IP电话的起始时间和终止时间等信息送给相应的计费中心。对于记帐卡用户，计费采集点还要接收相应计费中心送来的用户使用IP电话的最大时长，并实时监测用户的通话时间，以免用户透支。
9．2 计费方式
普通IP电话实行对主叫方计费。IP电话的费用包括普通电话网的使用费和IP电话网的使用费。IP电话以时长（对普通用户）或流量（如对专线用户）来收费。
IP电话的费用一一费率×时长（或流量）对于费率，各运营商可以根据实际需要，在不违反其他法规的前提下灵活调节。
9．3 计费和结算流程（针对二级结构的结算系统）
9．3．1 主叫号计费用户的计费流程
在用户通过接入授权认证并开始通话时，由计费采集点启动计费计数器，在用户拆线或网络拆线时终止计费计数器，并将计费采集点采集的数据送到一级计费中心。由一级计费中心生成原始记录数据CDR（Call Detail Record），根据费率生成帐单。并汇总上交给一级结算中心。
9．3．2 记帐卡用户的计费流程（针对二级结构的结算系统）
记帐卡用户要求实时计费，并能实时断线。对于有余额限制的情况时，计费结算系统应具备计费监视功能。
在用户通过接入授权认证后，一级计费中心应从用户数据库（漫游用户应在其开户地计费中心查找）提取余额信息共折算成最大可通话时间传给计费采集点，计费采集点启动相应的定时器以免用户透支。开始通话时由计费采集点启动计费计数器，在用户拆线或网络拆线时终止计费计数器。由计费采集点将采集的数据送到一级计费中心，由一级计费中心生成原始记录数据CDR（Call Detail Record），一级计费中心根据费率生成用户帐单，从记帐卡用户的余额中扣除（对漫游用户应将帐单送到其开户地一级计费中心，由它负责从记帐卡用户的余额中扣除），并汇总上
交给一级结算中心。
9．3．3 计费结束流程
9．3．3．1 电话用户发起呼叫的计费结束指示的通信流程
l）网关收到PSTN侧来的REL消息，或IP侧来的Release Complete消息时，停止计费计数器，收集计费信息，利用"脱离请求"（DRQ）消息发送到网守；
2）网夺利用"计费请求"（AccountRequest）消息将计费信息发送Radius服务器。如果是漫游用户，处理步骤3），否则处理步骤4）。
3）RADIUS服务器利用"计费请求"将计费信息发往远端RADIUS服务器，等待接收"计费响应"（Account－Response）消息。
4）RADIUS服务器向网守回送"计费响应。"
9．3．3．2 PC用户发起呼叫的计费结束指示的通信流程
l）PC用户向网守发送的"释放结束"（Release Complete）消息。
2）网守利用"计费请求"（ACCOulltRCquCSt）消息将计费信息发送RadiuS服务器，如果是漫游用户，处理步骤3），否则处理步骤4）。
3）RADIUS服务器利用，"计费请求"将计费信息发往远端RADIUS服务器，等待接收"计费响应（Account－Response）消息。
4）RADIUS服务器向网守回送"计费响应"。
实际上，被叫方的计费结束指示的通信流程和PC用户发起呼叫的计费结束指示的通信流程是一致的，只需要将图13的PC换为网关即可。
9．4 计费内容
9．4．1 主叫号码方式的一级计费中心（若无二级计费中心）计费清单的主要内容
内容如下：
--日期；
--开始时间；
--终止时间；
--通话时长；
--主叫用户号码；
--被叫用户号码；
--接入号码；
--入字节数；
--出字节数；
--业务类别；
--传真页数（对应IP传真）；
--主叫网守的IP地址；
--主叫网关的IP地址；
--被叫网守的IP地址（如果不能得到，该项可以省略）；
--被叫网关的IP地址；
--通话终止原因；
--编码方式等。
9．4．2 记帐卡方式的一级计费中心（若无二级计费中心）计费清单的主要内容
内容如下：
--日期；
--开始时间；
--终止时间；
--通话时长；
--卡号；
--接入号码；
--被叫用户号码；
--入字节数；
--出字节数；
--业务类别；
--传真页数（对应IP传真）；
--主叫网守的IP地址；
--主叫网关IP地址；
--被叫网守的IP地址（如果不能得到，该项可以省略）；
--被叫网关IP地址；
--通话终止原因等。
9．4．3单个运营者内结算中心之间的结算信息
结算中心之间的结算信息应至少包括以下内容：
--日期；
--开始时间；
--终止时间；
--通话时长；
--卡号（对于主叫用户，该项可以省略）；
--主叫用户号码（对于卡号用户，如果不能得到主叫号码，该项可以省略）：--接入号码；
--被叫用户号码；
--入字节数；
--出字节数；
--业务类别；
--传真页数（对应IP传真）；
--主叫网守的IP地址；
--主叫网关的IP地址；
--被叫网守的IP地址（如果不能得到，该项可以省略）；
--被叫网关的IP地址；
--通话终止原因；
--计费免费标志。
9．4．4 不同运营者之间的结算信息
结算中心之间的结算信息应至少包括以下内容：
--日期；
--开始时间；
--终止时间；
--通话时长；
--卡号（对于主叫用户，该项可以省略）；
--主叫用户号码（对于卡号用户，如果不能得到主叫号码，该项可以省略）；--接入号码；
--被叫用户号码；
--入字节数：
--出字节数；
--业务类别；
--传真页数（对应IP传真）；
--主叫网守的IP地址；
--主叫网关的IP地址；
--被叫网守的IP地址；
--被叫网关的IP地址（如果不能得到，该项可以省略）；
--通话终止原因；
--主叫号码的地址性质；
--被叫号码的地址性质；
--计费免费标志；
--运营者标识。
10 语音编码和传真的帧结构
10．1 概要
所有IP电话网的终端都应具有G．7if编解码器，并具备传送和接收A律和律的能力。终端编解码器的算法可以采用G．729和G．723．l等，并通过H．245能力协商来决定。作为几种标准的音频编解码，也可用RTP中分组类型（PT）来定义。如果支持G．723．l，则其编解码器既要支持5．3k算法也要同时支持6.3k 算法。鉴于编解码压缩比和算法时延对IP电话系统都十分重要，本标准建议优选G．729。
10．2 音频打包结构
10．2．1标准音频载荷类型（PT－PayloadWPe）
PT 编码名时钟（Hz）信道
0 PCMU 8000 1
8 PCMA 8000 1
9 G．722 8000 1
4 G．723 8000 1
15 G．728 8000 1
18 G．729 8000 1
10．2．2 对于fTU－T标准编码的打包结构
1）G．723．l
IP电话可以选用G．723．l编码。G．723．l的帧长有3种情况：24byte（6．3k/s）20byte（5．3k/s）和4byte。4byte为SID(插入静音描述帧）帧，它主要用在语音的静音段，用以发送比较舒适的噪声的参数描述。这3种帧可以用任意方式混合使用。第一个八位组的最低二个比特确定了帧的长度和编码类型。在30ms的帧边界上，这两种速率可以进行任意切换，以获得最佳的音质。所有编码比特流都是从最低有效位开始传送，直至最高有效位。
G．723．l打包特征为：
--用在RTP报头的标记住的置位方法，来表示该报文是静育以后第一个包。
--抽样频率为8000Hz。
--帧长为30ms。
--在一个包中，编解码器可以编解码几个连续的恢。
--接收机必须要能连续接收0～180ms的音频数据。
2）G．729
这是一种8kbit/s的编码算法，该种编码抗随机比特错误的能力与抗随机突发消失帧的能力相同。在噪声较大的
环境下，它能有更好的语音质量。G．729 annex A算法是G．729算法降低了复杂度后的版本，二者能完全互操作，因而不必对这两种算法进行区分。
在G．729 annex B中，建议声音激活检测器（V AD）和舒适噪声发生器（CNG）用于数字模拟声音和数字应用，可以和G．729、G．729 annex A结合使用。G．729帧长为10个八位组（octet），静音（annex B）为2个八位组。
有声段帧格式为：
--一帧为10ms。
--帧长10个八位组。
--一个RT包可以放零个、一个或多个G.29和G.729 annex A帧，后随G.729 annex B的有效载荷。舒适噪声帧的存在可以减小RTP载荷的长度。
--静音后的第一个有声包在RTP报头中标记位置位。
--抽样率8000Hz。
--缺省打包时间段20ms。
--编解码器可以进行单一包中连续l～10帧的编解码。
--接收方必须能接收0－200ms的用户语音数据。
3）G．728
帧的打包特征如下。
一个G728帧由4个10bit的矢量组成，它被装载成5个byte。
VI为最早的矢量，V4为最迟的矢量。在一帧中B1的最高特征位为该帧的最高特征位，BS的最低特征位为该帧的最低特征位。当打包在RTP中时，B1先被打包，B5最后打包。
多帧打包特征如下：
由于G．728帧过小，一包一帧则报头开销太大，因而G．728采用多帧打入一个包中。帧打包的方法如下：--G．728包可以打入多帧，但预设整数帧。
--最早的帧（最先播放的帧）第一个打入RTP包中。
-- 时戳为该包中第一帧第一个矢量的捕获时间。
4）G711
这是一种非压缩的编码方法，其数据直接来自PCM，采样率8000，其编码方法采用A律和μ律表。
10．3 传真的帧结构
10．3．1使用TCP协议的数据帧结构
TCP协议的数据帧结构如图16所示，其中IFP分组由两个字段组成。这两个字段是类型（TYPE）字段和数据（DA TA）字段。
10．3．2 使用UDP协议的数据帧结构。
11 网络管理
11．1 网络管理方式
网络管理采取集中管理方式，设置全网网管中心，负责完成各项管理功能。
11．2 网络管理对象
网管中必着重进行设备管理，其管理对象为各节点设备（网关和全国中心省中心等）。
管理的设备列表如下：
1）网关：
2）网守；
3 ) 计费/认证中心；
4）管理终端；
5）结算中心。
11．3 网管接口协议
由于目前大部分与IP有关的设备只支持SNMP协议，所以网管接口选择SNMP协议。11．4 网管接口信息模型网管中心和被管设备之间的网管信息模型采用一致的MIB库，其内容至少包括系统信息、配置信息、告警信息、性能统计信息等。详细内容可参见H．341协议。
11．5 网络管理功能
网管中心应实现的管理功能为配置管理、性能管理、故障管理和安全管理等。
11．5．1 配置管理
配置管理具有下列功能：
--配置管理数据库。创建并维护一个数据库，其中包含网络设备、软件、操作级别、负责维护设备的人员等信息。
--管理设备的配置文件。可以访问被管理设备的配置文件，并在必要时分析和编辑。
--网络节点设备部件端口配置。
--网络节点设备系统软件的配置。
--网络业务配置。网络节点各种数据的初始配置与修改，网络各种业务政策的配置与管理。
--对配置操作过程的记录统计。
11．5 性能管理
配置管理具有下列功能：
--自动获取网络拓扑结构及网络的配置，实时监控设备的状态。
--通过对被管理设备的监控和轮询，获取有关网络运行的信息及统计数据；并能在所收集的数据的基础上，提供网络的性能统计，例如：
·网络节点设备的可利用率；
·网络节点设备的CPU利用率；
·网络节点设备的故障率；
·网络延时统计；
·带宽统计利用率等。
--对历史统计数据的分析功能。
--优化网络性能，消除网络中的瓶颈，实现网络流量的均匀分布。
--提供手工设置性能的功能，如流量、压缩方法等。
11．5．3 故障管理
故障管理具有下列功能：
--生成错误日志，对日志进行维护并形成故障统计；
--针对错误检测报告作出反应；
--跟踪、辨认错误；
--执行诊断测试；
--手动或者自动纠正错误、排除故障等。
11．5．4 安全管理
安全管理应包括数据安全和系统安全，具有如下功能：
--系统安全
网管系统采取高级别、多层次的安全防护措施；
网管系统应提供严格的操作控制和存取控制；
自动记录非法信息，并将系统的状态自动记录，以便系统出现安全问题时能够容易地找到原因。
--数据安全
对各种配置数据、统计数据采取备份、保护措施；
采用多级别的方法，备份用户数据。
--人工或手工修复
当网络系统出现故障时，能自动及人工恢复正常工作，不影响网络的正常运行等。
11．5．5业务管理
a)用户数据管理
主要包括：
--用户数据的录入（增）；
--用户数据的删除（删）；
--用户数据的修改（改）；
--用户数据的查询（检索）。
b）网关数据的管理
主要功能包括：
--网关数据的录入（增）；
--网关数据的删除（删）；
--网关数据的修改（改）；
--网关数据的查询（检索）。
c）统计
统计的内容主要有：
--呼叫频度；
--有效呼叫数；
--呼损率；
--通话中断频度；
--接通率；
--各向平均时延；
--网络通信量（流量和流向）；
--不同目的的用户使用次数；
--用户平均每一次使用时长。
12 IP电话/传真网络的主要设备及功能
IP电话/传真网络除IP网外主要由六大部分组成，它们是网关、网守、受理终端、计费/认证中心、结算中心和网管。
12．1 网关
网关是跨接在电路交换网和IP网之间的设备，它的主要功能为：
--完成PSTN、ISDN、GSM侧的呼叫建立和释放，以及IP网络侧的呼叫建立和释放。
--完成语音编码和打包、回声消除、静音检测并提供收端缓存等功能。
--完成语音编码方式的转换和信令协议的转换。
--能够在通话开始时采集计费信息，并在通话结束时或定期向计费/认证中心传送计费信息。
--能够自动识别语音、传真业务。
--实现T.30和T.38通信规程。
--实现H．323、H．225、H．245、RTh、RTCP、ISUP、TUP、DSSI、中国1号信令等协议。
--能够支持多种语音编码，包括G．711、G．723和G．729。
--提供用户交互信息和查询。
--具有与网管设备的接口，完成配置、统计、故障查询、告警等功能。
--具有外同步接口，与现有同步网连接。
--网络QoS的测试。
12．2 网守
网守的主要功能为：
--地址解析，地址映射可以在网守处实现，也可以在网关处实现。
--支持H．323、H．225、H．245协议和RADIUS协议。
--带宽管理（任选）。
--呼叫控制。
--提供安全性管理。
--提供路由管理。
--具有与网管设备的接口，完成配置、统计、故障查询、告警等功能。
12．3 受理终端
IP电话/传真系统采用分散管理集中受理的模式。因而在系统中受理终端数量是较多的。一个营业点至少有一台受理终端，受理终端是营业受理点的营业员与计费/认证中心的接口，营业受理点的营业员通过受理终端完成用户帐号登记和注销的管理。
受理终端与计费/认证中心以B-S模式工作，受理终端为Browser（浏览器），计费／认证中心为server（服务器）。用户数据的增删改用Web来实现。
12．4 计费／认证中心
计费/认证中心负责接收计费采集点采集的用户计费信息，根据费率生成帐单，接受由网守发起的用户接入认证请求，对用户使用IP电话的权限进行认证并支持卡号用户的漫游认证。
12.5 结算中心
见第9章
12.6 网管
见第11章。
13 通信协议和流程
13．1 消息定义
13．1．IRAS消息
RAS消息主要遵循H．323v2协议，所有的RAS消息均采用ICV加密。具体内容如下。
13．1．1．1注册登记消息
a）MRQ（Registration Request）
本标准规定网关向网守以及受理终端向计费/认证中心发送注册信息时采用RRQ消息，具体内容如表8所示。网关必须定期（小于RCF的timetolive确定的时间）向网守发送RRQ消息，以表明网关仍然存活，具体的超时和重发次数要求见RAS消息的定时器及重发次数。
注：网关在首次注册时应将RRQ消息中的discovnycomplete置0，其余报告其存活的RRQ消息的discoerycomplete 置1。
b) RCF(Registration Confirm)
RCF是对RRQ消息的确认回答。
c）RRJ(Registration Reject)
RRJ是对RRQ消息的拒绝回答。
13．1．1．2 注销消息
a）URQ（Unregistrtion Request）
网关向网守发送的或PC向网守发送和请求注销注册登记的命令。
b）UCF（Unergistrtion Confirm）
网守向网关或PC发送的关于网关或PC的URQ的确认回答。
c）URJ（Unregistrtion Rject）
网守向网关或PC发送对URQ的拒绝回答。
13．1．1．3 修改消息
修改消息MRQ/MCF/MRJ是受理终端与计费/认证中心交互的信息，本标准只对其至少应具有的功能作了限制，至于其具体实现方式，则不在本标准的范围之内。
aMRQ（Modification Request）
受理终端向计费/认证中心发送修改用户数据的请求。
b）MCF（Midification Confirm）
计费/认证中心向受理终端发送的对修改用户数据请求消息。消息内容至少有表15所示的内容。
d）MRJ（Midification Reject）
计费/认证中心向受理终端发送的对修改用户数据请示的拒绝消息。消息内容至少有表16所示的内容。13．1．1．4 接入认证
a）ARQ
ARQ是网关向网守发送的用户接入认证、地址解析和修改密码请求消息，在非标准参数中我们添加了三项，第一为主叫控制方式，适用于主叫号码用户，第二为卡控制方式，对应于它分为三步，step1用于接入认证，step2用于地址解析，step3用于卡号用户在线修改密码。
b）ACF
网守对ARQ的确认回答，对于卡号用户，还需要给出用户余额或最长通话时长。
c）ARJ
网守对ARQ的拒绝回答，并给出拒绝原因。
13．1．1．5 地址解析请求消息
a）LRQ（Location Rquest）
网守向上一级网守发送的地址解析请求。
b）LCF（Location Confirm）
上一级网守对LRQ的确认回答，并经出地址解析结果。
c）LRJ（Location Reject）
上一级网守对LRQ的拒绝回答，并给出拒绝原因。
13．1．1．6 呼叫脱离消息
a）DRQ（Disengage Request）
网关与网守之间的呼叫脱离请求命令。当该命令由网关发起时．本消息应同时传递计费信息。计费信息放在"非标准数据"（NonstandardData）中。若是网守向网关传送DRQ消息，该消息不包含计费费信息，并且网关必须回应DCF。
c）DCF（Disengage Confirm）
对DRQ的确认回答。
d）DRJ （Disengage Reject）
网守对DRQ的拒绝回答，并给出拒绝原因。
13．1．1．7 状态消息
a）IRQ
网守向网关发的询问某一话路或所有话路的状态请求消息。消息的主要内容如表26所示。若callReference V alue 为0，则网关需要在同一条IRR消息中报告所有呼叫的状态信息。CallRferenceV alue为0的IRQ 的发送间隔应＞10s。
b）IRR
网关根据ACF命令设定的间隔或IRQ 请求向网守发送的状态消息。
c）IACK
对IRR的证实消息。
d) INAK
对于IRR的拒绝消息。
13．1．1．8 带宽改变消息
a）BRQ
网关与网守之间的带宽改变的请求的消息，当网守具备带宽管理能力时，则带宽管理消息是有实用意义的。由于ARQ消息的bandwidth所取的值总是大于每一话路实际占用的带宽，因此为了能使网守掌握网关的带宽利用情况，网关应根据实际带宽利用情况利用BRQ消息改变带宽，以便释放多余的带宽或请示增加带宽。若是利用BRQ消息增加带宽，则网关必须等待网守的确认。
b）BCF
网关或PC与网守之间带宽改变的确认的消息。
c）BRJ
网关或PC与网守之间的带宽改变的拒绝的消息。
13．1．1．9 网关资源可利用性消息
a）RAI
b）RAC
13.1.1.10 RAS的请求进展消息（RIP）
RIP消息是当终端收到一个请求消息后，如果判断在相应的超时（timeout）时间内不能及时返回回答消息，则该终端可通过发送RlP，消息以延长对方等待时间，这个等待时间由RIP消息的delay域决定。对端在timeout加delay 的时间内若没有收到回应则作超时处理。
13．1．2 顶级网守间消息
13．1．2．1业务请求（Service Request）
顶级网守间建立业务关联关系的请求。
13．1．2 业务确认（Service Confirmation）
收到业务请求的顶级网守对SerVice Request的确认回答。
13．1．2．3 业务拒绝（Service Rgection）
顶级网守对Service Request的拒绝回答，并给出拒绝原因。
13．1．2．4 描述器ID请求（DescriptorI DRequest）
顶级网守向别的顶级网守请求描述器ID的请求。
13．1．2．5 描述器ID确认（Descnptor IDConfirmation）
顶级网守对Descriptorl DRequest消息的确认回答，并给出该顶级网守的描述器ID列表。
13．1．2．6 描述器ID拒绝（Descnptor IDRejection）
顶级网守对Descriptor IDRequest消息的拒绝回答，并给出拒绝原因。
13．1．2．7 描述器请求（Descriptor Request）
顶级网守向另一个顶级网守请求特定描述器的内容。
13．1．2．8 描述器确认（Descriptor Confirmation）
顶级网守对Descriptor Request的确认回答，并给出描述器的具体内容。
13．1．2．9 描述器拒绝（Descriptor Rejection）
顶级网守对Descriptor Request的拒绝回答，并给出拒绝原因。
13．1．2．10 地址解析请求（AccessRequest）
顶级网守间的地址解析请求。
13．1．2．11 地址解析确认（Access Confimatlon）
顶级网守对地址解析请求的确认回答。
13．1．2．12 地址解析拒绝（Access RCJectlon）
顶级网守对地址解析请求的拒绝回答。
13．1．3 Q．931消息
Q．931的消息具体内容参见附录A，目前可使用以下的Q．931消息。各消息的主要内容见表48～表58。
a) 呼叫建立（Setup）
b）呼叫进程（Call Proceeding）
C）提醒（Alerting）
d)进展（Progress）
e)连接（Connet）
F)通知（Notify）
g)状态(Status)
h）状态询问(Status Inquiry)
i）用户信息(User Information)
j）释放完成(Release Complete)
k）设施(Facility)
13．1．4 H.245消息
13．1．4．1 终端能力设定
a）TCS（Terminal Capability）
b）TCSA（Terminal Capability Set Acknowlege）
c）TCSR（Terminal Ｃapability Set Reject）
13．1．4.2主从决定
在建立H．245通道过程中，可以使用主从决定，也可以不使用，对于IP电话，本标准建议不采用此流程。
a）MSD（Master Slave Determination）
b）MSDA（Master Slave Deterlmnatlon Acknowlege）
c）MSDR（Master Slave Deternunatlon叫ect）
13．1．4．3 打开逻辑通道
a)OLC（Open Logical Channel）
b）OLCA（Open Logical Channel Acknowledge）
c）OLCR（Open Logical Channel Reject）
13．1．4．4结束会话
13．1．4．5关闭逻辑通道
a）CLC（Close Logical Channal）
b）CLCACK（Close Logical ChannelAck）
13．1．5 RADIUS
13．1．5．1 RADIUS数据格式定义
a) 数据格式定义
b) 编号定义
13．1．5．2 属性定义
a) 属性数据格式定义
b) 类型定义
13．2 通信流程
13．2．1 呼叫流程
对于呼叫流程,要标准暂时只考虑到电话到电话和PC到电话两种业务方式.
13．2．1．1 呼叫建立流程
a) 电话到电话的呼叫建立流程
本标准建议采用快速呼叫建立过程(fastStart),对于无法做到的情况下，也可以采用非快速建立方式。发送快速呼叫建立请求时，如果对方不支持快速呼叫，发端必须能够倒成非快速连接。发端网关可以设定有接入认证和地址映射表的缓冲区，也可以不设定，如果设定有，则需要先利用缓冲区的数据进行接入认证和地址解析，失败时需再向管理中心发出接入认证或地址解析请求。
--快速呼叫建立流程
1）用户拨打IP电话，输入卡号密码；
2）网关1向网守发送ARQ消息，进行接入认证，其中就应包含主叫号码或卡号（主叫号码采用E.164编码）；
3）网守回送ACF，接入认证通过；
4）用户输入被叫号码；
5）网关1向网守发送ARQ进行地址解析；
6）地址解析通过后，网守发送ACF；
7）网关1向被叫网关2发起呼叫建立请求" Setup"，里面包含有H．245的通道消息；
8）网关2向网关互发送"呼叫进展"（Call Proceeding）消息，里面可以包含有H．245的通道信息，也可以没有；
9）网关2同时向网守发送ARQ消息；
10）网守向网关2发送认证通过消息ACF；
11）网关2向被叫发送呼叫建立请求消息；
12）被叫振铃；
13）网关2向网关1发送Alertng消息，该消息中，可以包含H245的通道信息，也可以不包含，网关1需要识别这两种不同情况；
14）网关1收到Alerting消息后，产生回铃音；
15）被叫摘机；
16）网关2向网关1发送"连接"（Connect）消息，里面可以包含有H．245的通道信息，也可以不包含，网关1需要识别这两种不同情况；
17）网关1收到Connect消息，接通主叫。
注：在快速呼叫过程中，网关1只有在收到Connect消息后才能开始发送媒体信息。
--非快速呼叫建立流程
1）用户拨打IP电话，输入电话密码；
2）网关1向网守发送ARQ消息，进行接入认证；
3) 网守回送ACF,接入认证通过；
4）用户输入被叫号码；
5) 网关1向网守发送ARQ进行地址解析；
6）地址解析通过后，网守发送ACF；
7) 网关1向被叫网关2发起呼叫建立请求Setup消息；
8）网关2向网关1发送"呼叫进展"（Call Proceeding）消息，里面可以包含有H．245的通道信息，也可以没有；
9）网关2同时向网守发送ARQ消息；
10）网守向网关2发送认证通过消息ACF；
11）网关2向被叫发送呼叫建立请求消息；
12）被叫振铃；
13）网关2向网关1发送Alerting消息，该消息中可以包含H．245的通道信息，也可以不包含，网关1需要识别这两种不同情况；
14）网关1收到Alerting消息后，产生回铃音；
15）被叫摘机；
16）网关2向网关1发送"连接"（Connect）消息，里面可以包含有n．2'5的通道信息，也可以不包含，网关1需要识别这两种不同情况，被叫开始计费（建议被叫网关在Connect消息中携带H．245地址）。
17）网关1收到Connect消息，接通主叫，主叫开始计费。
18）网关之间进行能力交换；
19）打开逻辑通道。
注：在非快速连接中，不再作主从判决，约定主叫为主，被叫为从。若在Connect消息后，H．245能力交换或打开逻辑通道失败，网关可将DRQ消息的tendnalCause置为establishedFailed，网守可以根据它不对用户进行计费。
b）PC到电话的呼叫建立流程
本标准规定PC到电话需要经过网守。呼叫建立流程如图25所示，以快速呼叫为例描述PC到电话的呼叫建立流程（PSTN侧信令以ISUP为例）。
l）PC用户向网守发送"请求用户接人认证"（ARQ）消息；
2）网守接收到来自网关1的ARQ消息后，检查用户合法性，确定用户权限，并进行地址翻译，将接入认证通过和授权（ACF）或拒绝（ARJ）消息发送到PC用户，PC用户在收到ACF消息后，作进一步处理，收到AIU消息后，做拆线处理；
3）PC用户向网守发起呼叫建立请求setup消息，里面包含有H．245的通道信息；
4）网守向被叫网关发起呼叫建立请求Setup消息，里面包含有H．245的通道信息；
5）被叫网关向网守发送Call Proceeding消息，里面可以包含或不包含H．245的通道信息；
6）网守向PC发送Call Proceeding消息，里面可以包含或不包含H．245的通道信息；
7）被叫网守向被叫用户发送IAM；
8）被叫网关收到PSTN发回的ACM信号时，被叫振铃；
9）当网守收到来自被叫网关的ALERT后，向PC发送ALERT消息；
10）被叫摘机，被叫网关收到ANM消息。向网守发送"连接"（Connect）消息；
11/12）网守收到Connect消息，启动计费计数器，同时向PC用户发送Connect消息，里面可以包含或不包含H．245的通道信息（建议被叫网关在Connect消息中携带H．245地址）。
13．2．1．2 国际呼叫建立流程
国际呼叫需要经过顶级网守进行呼叫建立。
13．2．1．3通话
在完成了呼叫建立过程以后，双方就进入通话状态。
在通信过程中，通过PSTN发送端用户将语音不断传送到发送端网关，发送端网关对语音进行压缩、编码，然后将编码后的语音打包，送入IP网。接收端网关接收来自IP网的语音包，拆包，然后对语音进行解码处理，通过PSTN 网传送到接收方。
通话过程要面向连接的，对每一个话路建立一个RTP连接。
在通话过程中，网关1和网关2之间相互发送RTCP包，以测试网络环境情况（如网络丢包率，通断情况等）。13．2．1．4呼叫释放流程
呼叫释放应采用互不控方式，分两种情况：
l）主叫用户先挂机；
2）被叫用户先挂机。
当计费采集点收到以下3类消息的时候，开始进行停止计费处理。
l）收到PSTN网侧来的REL消息；
2）收到IP网侧发来的Release Complete消息；
3）收到底侧的网络故障消息。
以主叫用户先挂机为例描述呼叫释放流程。
1）主叫挂机；
2）如果已打开H.245通道,则网关之间要先关闭逻辑通道;
3）如果已打开H.245通道,则关闭逻辑通道后,网关间互送End Session Command;
4）网关１向网关２发送Rlease complete消息；
5）网关２挂断被叫;
6）网关1向网守发送DRQ;
7）网守向网关1发送DCF;
8）网关2向网守发送DRQ;
9）网守向网关发送DCF.
注:6)、7）、8）、9）的顺序无严格要求。
13．2．2 IP传真的呼叫流程
CED（被叫终端标识）：2100Hz信号，标识收端传真机。
CSI（被叫用户标识）：本信号选用，可用来传送收端传真电话号码。
DIS（数字标识信号）：表征该设备是ITU标准性能的，即收端传真能力信号（包括纸张大小、扫描密度等参数）。
TSI（发送用户标识）：本信号选用，标识发端传真机。
DCS（数字命令信号）：数字建立命令，发端根据收端DIS中的能力集合，协商出的最终通信能力集合。
TCF（训练检验）：用于通信电路的训练。
CFR（可以接收的证实）：证实全部报文前过程已经完成，并可开始报文传输。
EOP（过程结束）：表示一页传真协议的结束。
MCF（报文证实）：表示已经收到完整的报文，并可继续收另外的报文。
注：本流程应在主叫网关收到CONNECT命令之后进行。
13．2．3 设备登录和注销流程
13．2．3．1网关设备的登录流程
网关设备在运行初期需要向受理终端登记，由受理终端向网守登记注册。
13．2．3．2 网关设备的注销流程
13．2．3 用户登记和注销流程
13．2．4．1 用户登记流程
13．2．4．2 用户注销流程
13．2．5 顶级网守之间进行描述器交换流程
14系统安全性
IP电话的安全性包括以下4个方面：
l）网络安全；
2）身份认证及接人控制；
3）音频数据流的完整性保护；
4）音频数据流的加密。
14．1网络安全
对网管中心、计费/认证中心、结算中心、网守和重要数据库设置防火墙保护。网络的重要设备要有冗余备份。14．2身份认证和接入控制的安全
二级网守应支持基于RAS协议的用户认证方式，当用户漫游认证时，二级网守和一级网守的通信可采用RADIUS 协议。
网关和网守之间的身份认证利用ARQ/ACF信息：
网关向网守发送ARQ信息，网关需要填充ARQ信息中的安全域。收到ARQ信息，网守根据以下的规则验证认
一、SIP协议介绍： 会话发起协议SIP（Session Initiation Protocol）是一个应用层控制信令协议，用于建立、更改和终止多媒体会话或呼叫。SIP作为一个基础，可以在其上提供很多不同的服务。目前已经定义的媒体类型有音频、视频、应用、数据、控制。 二、SIP呼叫流程： 注册流程： （1）用户首次试呼时，终端代理A 向代理服务器发送REGISTER 注册请求； （2）代理服务器通过后端认证/计费中心获知用户信息不在数据库中，便向终端代理回送401Unauthorized 质询信息，其中包含安全认证所需的令牌； （3）终端代理提示用户输入其标识和密码后，根据安全认证令牌将其加密后，再次用REGISTER 消息报告给代理服务器； （4）代理服务器将REGISTER 消息中的用户信息解密，通过认证/计费中心验证其合法后，将该用户信息登记到数据库中，并向终端代理A 返回成功响应消息200 OK。 呼叫流程：
（1）用户摘机发起一路呼叫，终端代理A 向该区域的代理服务器发起Invite 请求；（2）代理服务器通过认证/计费中心确认用户认证已通过后，检查请求消息中的Via 头域中是否已包含其地址。若已包含，说明发生环回，返回指示错误的应答；如果没有问题，代理服务器在请求消息的Via 头域插入自身地址，并向Invite 消息的To 域所指示的被叫终端代理B 转送Invite 请求； （3）代理服务器向终端代理A 送呼叫处理中的应答消息，100 Trying； （4）终端代理B 向代理服务器送呼叫处理中的应答消息，100 Trying; （5）终端代理B 指示被叫用户振铃，用户振铃后，向代理服务器发送180 Ringing 振铃信息； （6）代理服务器向终端代理A 转发被叫用户振铃信息； （7）被叫用户摘机，终端代理B 向代理服务器返回表示连接成功的应答（200 OK）；（8）代理服务器向终端代理A 转发该成功指示（200 OK）； （9）终端代理A 收到消息后，向代理服务器发ACK 消息进行确认； （10）代理服务器将ACK 确认消息转发给终端代理B； （11）主被叫用户之间建立通信连接，开始通话； 结束流程：
ＳIP应答消息状态码与类型状态码状态说明?临时应答(１XＸ）１00 Tｒying 正在处理中 182ｑuｅue 排队 18１ｃall being forwarｄeｒ呼叫正在前向? 180Ringiｎｇ振铃? １81* sessiｏｎproｇｒesｓ会话进行 会话成功（２XＸ）２0０OK 会话成功 重定向（3XＸ）300 ｍultiｐle 多重选择 301 moved pｅｒｍaneｎtｌy 永久移动 302 moveｄteｍporaily 临时移动 ３05 use pｒoxy 用户代理 380 alｔeｒnative seｒvice 替代服务 请求失败(4XX) 40０bad rｅqueｓt 错误请求?４0１unａuthｏrizeｄ未授权 402 ｐayment required 付费要求 403 ｆorbidden禁止 ４04 not found 未发现 40５ｍethod ｎo alｌowed 方法不允许 ４０6 ｎot acceptable 不可接受?4０7 ｐｒoxｙaｕｔhentｉcatｉon reqｕirｅd 代理需要认证?4０8ｒequest timeouｔ请求超时?４１０gｏne离开 41４reqｕest—url too lｏng 请求ＵRL太长?4１5 4１3 request ｅｎtity tｏo large请求实体太大? uｎsupported media typｅ不支持得媒体类型 416unｓｕｐporｔeｄurl scheme 不支持得URL计划? 420ｂａd extｅｎｓｉon 不良扩展?4２1e xｔensｉon ｒｅqｕired需要扩展 481call/ｔran 42３intervａｌtoo ｂrｉｅf间隔太短?4８0 temporａrily uｎavaiｌａble临时失效? 482lｏoｐｄｅtectｅd 发现环路?4８3 too m ｓaｃtiｏｎｄｏes not eｘiｓt 呼叫／事务不存在? 485amｂigｕous 不明朗? 48６busy 484ａｄdrｅss iｎplete 地址不完整? ａnyｈoｐs跳数太多? hｅｒe这里忙 4８7requesｔterｍinateｄ请求终止?4８８nｏt acceptaｂle ｈere 这里请求不可接受 49１request pｅndiｎg 未决请求 ４93unｄecｉｐheｒaｂｌe不可辨识 服务器失败（5ＸＸ）500seｒｖer iｎternal error 服务器内部错误5?０1 noｔimpｌementeｄ不可执行 502 bad gatewａy 坏网关 503 sｅrｖice unａvaｉlable 服务无效? 50５veｒsｉon n 50４ｓeｒｖeｒtiｍe－oｕt 服务器超时? oｔｓupportｅｄ版本不支持 513message toｏｌarge 消息太大 全局性错误（6XＸ) 600 busy everｙwhere 全忙?6０3 declinｅ丢弃?６04 does not exｉｓtａｎy ｗheｒe不存在 ６０6 not aｃceptabｌｅ不可接受 SＩP应答代码(以下就是详细内容） 应答码就是包含了，并且扩展了/1、1应答码。并不就是所有得/1、1应答码都适当应用,只有在折里指出得就是适当得.其她／1、1应答码不应当使用。并且,SIP也定义了新得应答码系列,６xｘ。 1 临时应答１xx?临时应答，也就就是消息性质得应答，标志了对方服务器正在处理请求，并且还没有决定最后得应答。如果服务器处理请求需要花20０ms以上才能产生终结应答得时候，它应当发送一个１xx应
SIP协议学习总结 1、SIP协议定义 SIP（Session Initiation Protocol，即初始会话协议）是IETF提出的基于文本编码的IP电话/多媒体会议协议。用于建立、修改并终止多媒体会话。SIP 协议可用于发起会话，也可以用于邀请成员加入已经用其它方式建立的会话。多媒体会话可以是点到点的话音通信或视频通信，也可以是多点参与的话音或视频会议等。SIP协议透明地支持名字映射和重定向服务，便于实现ISDN，智能网以及个人移动业务。SIP协议可以用多点控制单元（MCU）或全互连的方式代替组播发起多方呼叫。与PSTN相连的IP电话网关也可以用SIP协议来建立普通电话用户之间的呼叫。 SIP协议在IETF多媒体数据及控制体系协议栈结构的位置 H.323SIP RTSP RSVP RTCP H.263 etc. RTP TCP UDP IP PPP Sonet AAL3/4AAL5 ATM Ethernet PPP V.34 SIP协议支持多媒体通信的五个方面： ◆用户定位：确定用于通信的终端系统； ◆用户能力：确定通信媒体和媒体的使用参数； ◆用户有效性：确定被叫加入通信的意愿； ◆会话建立：建立主叫和被叫的呼叫参数； ◆会话管理：包括呼叫转移和呼叫终止； SIP协议的结构 SIP是一个分层的协议，也就是说SIP协议由一组相当无关的处理层次组成，这些层次之间只有松散的关系。 SIP最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar (BNF范式)。 第二层是传输层。它定义了一个客户端发送请求和接收应答的方式，以及一 个服务器接收请求和发送应答的方式。所有的SIP要素都包含一个通讯层。 第三层是事务层。事务是SIP的基本组成部分。一个事务是UAC向UAS发送的一个请求以及UAS向UAC发送的一系列应答。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。任何一个用户代理客户端完成的事情都是
Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。 一、介绍 Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。但缺点也专门明显，首先确实是可用性差，没有专门好的api封装，使得上层应用在调用协议栈时专门破裂；其次，只做到了transaction层次的协议过程解析，
缺少call、session、dialog等过程的解析，这也增加了使用的难度；再次，缺少线程并发处理的机制，使得它的处理能力有限。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。eXosip增加了call、dialog、registration、subscription等过程的解析，使得有用性更强。然而eXosip局限于UA的实现，使得它用于registrar、sip server等应用时极其不容易。另外，它并没有增加线程并发处理的机制。而且只实现了音频支持，缺少对视频和其它数据格式的支持。 综合来讲，Osip2加上eXosip协议栈仍然是个实现Sip协议不错的选择。因此需要依照不同的需求来增加更多的内容。 二、Osip2协议栈的组成 Osip2协议栈大致能够分为三部分：sip协议的语法分析、sip 协议的过程分析和协议栈框架。 1、Sip协议的语法分析：
要紧是osipparser2部分，目前支持RFC3261和RFC3265定义的sip协议消息，包括INVITE、ACK、OPTIONS、CANCEL、BYE、SUBSCRIBE、NOTIFY、MESSAGE、REFER和INFO。不支持RFC3262定义的PRACK。 遵循RFC3264关于SDP的offer/answer模式。带有SDP的语法分析。 支持MD5加解密算法。支持Authorization、www_authenticate 和proxy_authenticate。 2、Sip协议的过程分析： 要紧是osip2部分，基于RFC3261、RFC3264和RFC3265的sip 协议描述过程，围绕transaction这一层来实现sip的解析。 Transaction是指一个发送方和接收方的交互过程，由请求和应答组成。请求分为Invite类型和Non-Invite类型。应答分为响应型的应答和确认型的应答。响应型的应答是指那个应答仅代表
SIP应答消息状态码 与功能 类型状态码状态说明 临时应答(1XX) 100 Trying 正在处理中 180 Ringing 振铃 181 call being forwarder 呼叫正在前向 182 queue 排队 181* session progress 会话进行 会话成功(2XX) 200 OK 会话成功 重定向(3XX) 300 multiple 多重选择 301 moved permanently 永久移动 302 moved temporaily临时移动 305 use proxy 用户代理 380 alternative service 替代服务 请求失败(4XX) 400 bad request 错误请求 401unauthorized 未授权 402 payment required 付费要求 403 forbidden 禁止 404 not found 未发现 405 method no allowed 方法不允许 406 not acceptable 不可接受 407 proxy authentication required 代理需要认证408 request timeout 请求超时 410 gone 离开 413 request entity too large 请求实体太大 414 request-url too long 请求URL太长 415 unsupported media type 不支持的媒体类型416 unsupported url scheme 不支持的URL计划420 bad extension 不良扩展 421 extension required 需要扩展 423 interval too brief 间隔太短 480 temporarily unavailable 临时失效 481 call/transaction does not exist 呼叫/事务不存在482 loop detected 发现环路
SIP消息头域的说明(转) 1 general-header类： 为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。不被认可的头域作为实体头域。 1.1 Call-ID Call-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。 对于一个INVITE请求。主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确认。 使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。如果需要的话，可以使用在会话描述中的标识来检测此副本。例如，SDP的“o”域中包含了会话标识和版本号。 REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。 Call-ID = (“Call-ID” | “i”)”:”local-id”@”host Local-id = 1*uric i是Call-ID的缩写形式。 “host”应该是一个真正的域名或者是一个全球性的IP地址。如 此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯
Sip 响应状态码对照详解 SIP应答消息状态码 与功能 类型状态码状态说明 临时应答(1XX) 100 Trying 正在处理中 180 Ringing 振铃 181 call being forwarder 呼叫正在前向 182 queue 排队 181* session progress 会话进行 会话成功(2XX) 200 OK 会话成功 重定向(3XX) 300 multiple 多重选择 301 moved permanently 永久移动 302 moved temporaily临时移动 305 use proxy 用户代理 380 alternative service 替代服务 请求失败(4XX) 400 bad request 错误请求 401unauthorized 未授权 402 payment required 付费要求 403 forbidden 禁止 404 not found 未发现 405 method no allowed 方法不允许 406 not acceptable 不可接受 407 proxy authentication required 代理需要认证408 request timeout 请求超时 410 gone 离开 413 request entity too large 请求实体太大 414 request-url too long 请求URL太长 415 unsupported media type 不支持的媒体类型416 unsupported url scheme 不支持的URL计划420 bad extension 不良扩展 421 extension required 需要扩展 423 interval too brief 间隔太短 480 temporarily unavailable 临时失效 481 call/transaction does not exist 呼叫/事务不存在482 loop detected 发现环路 483 too many hops 跳数太多 484 address incomplete 地址不完整 485 ambiguous 不明朗 486 busy here 这里忙 487 request terminated 请求终止 488 not acceptable here 这里请求不可接受 491 request pending 未决请求 493 undecipherable 不可辨识
sip代码含义 1xx = 通知性应答 100 正在尝试 180 正在拨打 181 正被转接 182 正在排队 183 通话进展 2xx = 成功应答 200 OK 202 被接受：用于转介 3xx = 转接应答 300 多项选择 301 被永久迁移 302 被暂时迁移 305 使用代理服务器 380 替代服务 4xx = 呼叫失败 400 呼叫不当 401 未经授权：只供注册机构使用，代理服务器应使用代理服务器授权407 402 要求付费（预订为将来使用) 403 被禁止的 404 未发现：未发现用户 405 不允许的方法 406 不可接受 407 需要代理服务器授权 408 呼叫超时：在预定时间无法找到用户 410 已消失：用户曾经存在，但已从此处消失 413 呼叫实体过大 414 呼叫URI过长 415 不支持的媒体类型 416 不支持的URI方案 420 不当扩展：使用了不当SIP协议扩展，服务器无法理解该扩展 421 需要扩展 423 时间间隔过短
480 暂时不可使用 481 通话/事务不存在 482 检测到循环 483 跳数过多 484 地址不全 485 模糊不清 486 此处太忙 487 呼叫被终止 488 此处不可接受 491 呼叫待批 493 无法解读：无法解读S/MIME文体部分 5xx = 服务器失败 500 服务器部错误 501 无法实施：SIP呼叫方法在此处无法实施 502 不当网关 503 服务不可使用 504 服务器超时 505 不支持该版本：服务器不支持SIP协议的这个版本 513 消息过长 6xx = 全局失败 600 各处均忙 603 拒绝 604 无处存在 606 不可使用 SIP协议应答码 应答代码 应答码是包含了，并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应用，只有在折里指出的是适当的。其他HTTP/1.1应答码不应当使用。并且，SIP也定义了新的应答码系列，6xx。 1 临时应答1xx 临时应答，也就是消息性质的应答，标志了对方服务器正在处理请求，并且还没有决定最后
第一章SIP协议主要消息 1.1 SIP消息分类 SIP协议是以层协议的形式组成的，就是说它的行为是以一套相对独立的处理阶段来描述的，每个阶段之间的关系不是很密切。 SIP协议将Server和User Agent之间的通讯的消息分为两类：请求消息和响应消息。 请求消息：客户端为了激活特定操作而发给服务器的SIP消息，包括INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。 SIP请求的6种方法： 1、邀请（INVITE）——邀请用户加入呼叫 2、确认（ACK）——确认客户机已经接收到对INVITE的最终响应 3、可选项（OPTIONS）——请求关于服务器能力的信息 4、再见（BYE）——终止呼叫上的两个用户之间的呼叫 5、取消（CANCEL） 6、注册（REGISTER）——提供地址解析的映射，让服务器知道其它用户的位置 响应消息：服务器向客户反馈对应请求的处理结果的SIP消息，包括1xx、2xx、3xx、4xx、5xx、6xx响应 1.2 SIP消息结构 请求消息和响应消息都包括SIP消息头字段和SIP消息体字段； SIP消息头主要用来指明本消息是有由谁发起和由谁接受，经过多少跳转等基本信息； SIP消息体主要用来描述本次会话具体实现方式； 1.3 消息格式 1.3.1 请求消息格式 SIP请求消息的格式，由SIP消息头和一组参数行组成，如图1-1所示。通过换行符区分命令行和每一条参数行。
图1-1 SIP 请求消息结构 注意：参数行的顺序不是固定的。对应的参数解释见错误！未找到引用源。。 消息体定义： Call-ID ：头字段是用来将消息分组的唯一性标识 From ：头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。From 头字段包含一个URI 和一个可选的显示名称 CSeq ：头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致 Max-Fowords ：头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值，每经过一跳，这个值就被减一。如果在请求消息到达目的地之前该值变为零，那么请求将被拒绝并返回一个483（跳数过多）错误响应消息。 Via ：头字段定义SIP 事务的下层（传输层）传输协议，并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后，才能在请求消息中加入Via 头字段值。 expires ：参数指出了该值中包含的URI 地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数，那么URI 地址的有效期由Expires 头字段值来确定。 消息头
SIP 协议学习 1初识SIP 1.1 SIP定义 Session Initiation Protocol会话初始协议是基于文本的信令协议。是一个在IP网络上进行多媒体通信的应用层控制协议。用来创建、修改和终结一个或多个参与者参加的会话进程。 SIP协议可用于发起会话，也可用于邀请成员加入已经用其他方式建立的会话。 SIP基于文本编解码。采用事务机制，每一个请求出发Server的操作方法，请求和响应构成一个事务。事务间彼此独立。 SIP独立于底层传输协议。SIP协议承载在IP网，传输层协议可用TCP或UDP，推荐首选UDP。 SIP支持5方面功能： 1.用户定位：确定通信所用的端系统位置 2.用户能力交换：确定所用的媒体类型和媒体参数 3.用户可用性判定：确定被叫方是否空闲和是否愿意加入通信 4.呼叫建立：邀请和提示被叫，在主被叫之间传递呼叫参数 5.呼叫处理：包括呼叫终结和呼叫转移等 1.2 SIP特点 1.一个正在发展和不断研究中的协议。 2.简练、开放、兼容和可扩展等原则。 3.充分注意到因特网开放而复杂的网络环境下的安全问题。 4.充分考虑了对PSTN的各种业务，包括IN（Intelligent Network智能网）业务和ISDN业 务（Integrated Services Digital Network综合业务数字网）的支持。
2SIP协议 2.1 SIP协议结构 1.最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar(BNF 范式)。 2.第二层是传输层。定义了一个客户端如何发送请求和接收应答，以及一个服务器如何接 收请求和发送应答。所有的SIP要素都包含一个通讯层。 3.第三层是事务层。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的 超时。任何一个用户代理客户端（user agent client UAC）完成的事情都是由一组事务构成的。有状态的代理服务器包含一个事务层;无状态的代理服务器不包含事务层。 4.事务层之上是事务用户TU。每个SIP实体，除了无状态代理，都是一个事务用户。TU 可以创建客户事务，也可以取消客户事务。 2.2 SIP网络结构 User Agent Client (UAC) 用户代理客户端：是一个逻辑的概念，是请求的创建方。UAC 角色只在事务中存在。 User Agent Server(UAS) 用户代理服务器：是一个逻辑的实体，对SIP请求做出接受、拒绝或者转发的响应。UAS角色在事务中存在。 注：UAC和UAS，是在串行事务处理的原理上定义的。当主叫方A发出INVITE请求的
1.SIP 1.1.1.SIP格式 每条SIP消息由以下三部分组成： （1）起始行（Start Line）：每个SIP消息由起始行开始。起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。起始行可以是一请求行（请求）或状态行（响应）。 （2）SIP头：用来传递消息属性和修改消息意义。它们在语法和语义上与HTTP头域相同（实际上有些头就是借自HTTP），并且总是保持格式：<名字>:<值>。 （3）消息体：用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。消息体能够显示在请求与响应中。SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP 范围之外的会话描述信息。可能的体类型就包括本文将要描述的SDP会话描述协议。
1.1. 2.消息头 Header field where proxy ACK BYE CAN INV OPT REG Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alter-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * Cseq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o o Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c - o o o o o Retry-After 404, 413,
SIP协议与视频通信 关键字：SIP视频通信H.323 摘要：文章简要概述现有视频通信技术，包括H.320与H.323应用。然后介绍IETF可以用于视频通信的协议：SIP。在SIP介绍中首先描述SIP协议的历史，然后描述SIP的组成部件。明确部件后举例说明了一个SIP呼叫建立的流程。在第四部分通过与H.323协议族比较来说明SIP用于视频通信的优劣。最后指出SIP协议用于视频通信的前景。 引言 沟通是人类生存的基本需求，通信已成为现代生活中必不可少的内容。在任何时间，任何地点与人和人通信是电信发展的目标。通信技术发展到今天，电话网几乎覆盖全球。语音通信(电话)似乎已基本达到上述目标。但是随着技术的发展，人们已不满足仅仅语音通信。大规模视频通信已成为下一阶段信息产业发展方向。虽然电视会议已出现二十多年，当前不但统一的标准而且有成熟的产品；但是由于种种原因一直没有得到象电话那样的普遍应用。视频通信似乎一直是一座未被足量开采的金矿。随着传输技术的发展，带宽资源已不是瓶颈；随着一场SARS的肆虐，视频通信又成为热点。随着SIP协议的出现，视频通信在技术上又有了新的发展动力。 视频通信协议概述 基于H.320的视频应用 传统会议电视利用以电话网2M或者1.544M直联数字线路连接终端会议电视设备进行实时音频、视频和数据信息的传送。通过使用多点控制器，可以在一块控制板具备所有主会场的操作切换功能。最初会议电视厂家以各自专用的压缩和通信算法进行生产，各个会议电视厂家产品无法互联互通。 随着ITU-T推出H.320协议，上述问题得到很大程度的解决。H.320是同步电路交换网(如ISDN)上现频传输的标准。电路交换网适用于实时应用，如长时间和具有确定延迟的音频和视频信号传递。电路的建立依赖于带外信令、集中的路由控制和昂贵的交换设备。使用H.320协议，电话网上中商用会议电视的理想电路是384 kbps。使用384kbps的电路可以以合理的成本提供高质量的音频和视频信号。采用2M或者1.544M的中继直连当然很容易满足上述带宽要求，但是作等于建立专网，价格将令用户难以承受。 由于电话网络中继价格不断下降以及大量既成事实的基于H.320的电视会议应用，虽然H.320通信成本相对于现有的其它方式稍显昂贵，但其市场仍将在未来数年里继续成长——尽管其成长是缓慢的。 基于H.323协议的视频应用 H.323是国际电信联盟制定的局域网上的多媒体通信系列标准。该协议专门为不提供服务质量(QOS)保证的局域网技术制定，例如运行于以太网、快速以太网和令牌环网(Token Ring)上的TCP／IP和IPX。尽管H.323协议特别为局域网制定，只要带宽时延满足要求同样可以应用在更大范围例如城域网和广域网。1997年5月，国际电信联盟第15研究小组重新定义
2017年第2期信息通信2017 (总第170 期）INFORM ATION & COMMUNICATIONS (Sum. No 170) SIP协议介绍及应用前景分析 杜鑫 (中国人民解放军9155〇部队3分队） 摘要:S IP是一种源于互联网的IP语音会话控制协议，具有灵活、易于实现、便于扩展等特点。文章介绍了 S IP协议的发 展历史、网络组成，通过与传统的电信网络协议对比分析了 S IP协议的特点，结合S IP协议特点及现状对其应用前景进 行了分析。 关键词：SIP ;融合通信;VO LTE;互联网 中图分类号:TN913.23 文献标识码:A文章编号：1673-1131(2017)02-0105-02 1S IP协议的发展历史 SIP(Session Initiation Protocal)会话初始化协议的概念在 1996年出现，主要运用在Internet的不同文本类型当中，用于 电子邮件以及文字聊天等各项环节中。1999年由IE T F最初 建立，应用于Internet的相关网络环境结构当中，实现实时性 通讯。二H世纪初，由IE T F当中的S IP工作团队发出 RFC3261建议后才得到了逐渐推广。 S IP协议最初应用于Internet网络中，实现多媒体的会话 建立控制，后来作为IMS(IP M ultim edia Subsystem IP多媒体 子系统）的主要信令应用于电信领域的VOBB(V oiceover Broad Band宽带语音)，近年来随着LT E的推广，SIP成为LTE 的语音最终解决方案V O LTE的主要信令协议，其应用范围从 特定环境逐步扩展至主流多媒体通信环境。 2 S IP网络组成 2.1 S IP协议在IM S中的应用 S IP协议是IM S中的基本协议,应用于M w、U t、ISC、M i、M g、M j、M k、M r等众多接口，整个IM S网络的会话控制功能 都是由S IP协议完成，具体使用情况如图1所示： P-CSCF ATS IM-SSF SIPl 4 M RFC UGC 19 图1S IP协议在IM S网络中应用示意图 2.2 S IP网络架构 S IP使用CS(Client/server客户端/服务器)架构如图2所 示，交互形式为请求、响应的方式。User Agent C lie n t即客户 端，发起S IP请求;User Agent Server即服务器端，进行S IP请 求处理，并进行响应，Request Proxy Server起到消息路由转发的功能。 3.2认证测试标准 系统B模型采用的简表是07B0,根据K N X协议必须满 足如表1所列的功能需求。认证测试将会针对这些基本功能 来设计测试例进行测试。 按照测试规范[6]要求，先通过E TS配置软件配置好K N X 设备后，采用E IT T软件编写好测试例，运行测试序列，所有测 试例均通过，说明该协议栈符合K N X协议规范要求。在软件 开发过程中，可以通过该方式进行各个功能点的验证，从而保 证软件的可靠性，缩短最终的认证周期。 表1系统B的基本功能表 协议栈主要功能 数据链路层数据帧的封装和解析、应答、数据过滤 网络层正确设置路由计数器 传输层支持四种传输模式；支持style3的状态机 配置和管理直接内存访问；用户内存的直接内存访问；验证模式；接口对象处理；下载状态机；运行状态机；重启；授权；设备描述业务；编程模式；K N X序列号；地址表?，关 联表；组对象表；应用相关参数 4结语 本文介绍的系统B模型的K N X设备是基于LPC处理器、L in u x系统来设计和实现的，并采用了 NCN5120芯片作为 K N X总线收发模块。该设备通过了第三方认证测试实验室的 认证测试，符合K N X协议规范。系统B模型K N X具有更丰 富的资源，可应用于复杂的智能家居和楼宇控制系统中，具有 广阔的市场价值和应用前景。 参考文献： [1]夏长凤.基于K N X总线智能家居控制系统的设计[J].电 器自动化，2016, 38⑴. [2]任志勇.基于K N X智能家居的应用[J].重庆电子工程职 业学院学报,2010, 19(4). [3]Jason Richards,Development o f Complex K N X Devices. W EINZIERL ENGINNERING GmbH,2010. [4]Konnex Association.Konnex Standard,Vol3,System Specifications,2013. [5]Konnex Association.Konnex Standard,Vol6,Profiles,2013. [6]Konnex Association.Konnex Standard,Vol8,System Test Specifications,2013. 作者简介:朱莉(1979-)，女，四川省资中县人，电子工程师，硕 士学位，主要研宄方向为智能家居、大数据、LTE。 105
协议分析 协议扩展分析 STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ????STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?
SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK 与传统 Telephony 业务互通的场景 ?Encapsulation –'Transparent' Transit of ISUP Messages –SIP 与ISUP 协议不可能一一映射 –如果为了保证SP1－SP2之间业务的无缝互通，只有SP1发出的ISUP 消息能够透传到SP2–将ISUP 消息封装在SIP 消息体里–Content-Type: application/ISUP
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?可STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW Transaction STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???准?STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?规则CANCEL ???
SIP各类消息简介 1.消息简介 sip消息类型和消息格式 SIP是一个基于文本的协议,使用的是UTF-8字符集. SIP消息主要分为两大类: 一类是由客户端发往服务器的请求消息(Request); 一类是由服务器发往客户端的应答消息(Response). 一个基本的SIP消息包括起始行、一个或多个头字段、说明头字段结束的空行和一个可选的消息体。 消息=起始行（包括请求行/状态行；请求行规定了请求的类别，而状态行指出了每个请求的状态，比如是成功还是失败。如果是失败的话还要给出失败的原因或类型。） *头字段 CRLF [消息体] （消息首部给出了关于请求或应答的更多信息一般包括消息的来源、规定的消息接收方，另外还包括一些其他方面的重要信息。消息体通常描述将要建立会议的类型包括所交换媒体的描述，但不具体定义消息体的内容或结构，其结构或内容使用另外一个协议来描述，就是会话描述协议SDP。） 2.请求消息 请求行=方法+空格+请求地址+SIP版本号+空行 通过一个请求行作为起始行，请求行包括了方法名、请求的URL、协议版本号、中间用空格分开。 六种请求方法： INVITE 发出呼叫会话请求 ACK INVITE请求被最终请求 BYE 释放一个呼叫会话 CANCEL 取消挂起的呼叫 REGISTER 登记注册用户代理 OPTIONS 查询服务器能力 3.应答消息 状态行=SIP版本+空格+状态码+空格+相关文本短语+空行 SIP应答消息状态码与功能 类型状态码状态说明 临时应答(1XX) 100 Trying 正在处理中 180 Ringing 振铃 181 call being forwarder 呼叫正在前向 182 queue 排队
sip协议解析与实现(c和c++使用osip)11 第八章查询能力 SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息，而不用"呼叫(ringing)"另外一端。例如，在客户端插入了一个Require头域到INVITE 中，并列出了不确定目标UAS是否支持的能力之前，它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。 OPTIONS方法的目标使用Request-URI来标识，因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器，Request-URI不由客户端设置，这类似于REGISTER请求设置Request-URI的方法。 如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求，它要对这个请求进行应答而不用管Request-URI. 这个行为与HTTP/1.1一致。这个行为可以被用于"追踪路由线路(traceroute)"功能，从而使用发送一系列递增的 Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。
作为一般UA的行为，如果OPTIONS长时间没有应答，事务层能够返回一个超时错误。这将指出，目标是不可到达的并且查询的能力是不可以使用的。 OPTIONS请求可能由建立一个对话的一端发送，用于查询对端在后面的对话中可能会被使用到的能力。 第一节构造OPTIONS请求 OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。 OPTIONS可能会有一个Contact头域。 应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的，这可能被设置成用来描述UA的媒体能力的类型，比如，SDP(application/adp)。OPTIONS请求的应答被认为是有限定范围的，它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送，它保证会话中后继的请求也由应答OPTIONS的服务器所接收时，对OPTIONS请求的应答才是可用的。 OPTIONS请求的例子： OPTIONS sip:carol@https://www.doczj.com/doc/c714880078.html, SIP/2.0 Via: SIP/2.0/UDP https://www.doczj.com/doc/c714880078.html,;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70