IP电话、IP传真业务总体技术要求(下)_Offt的空间_百度空间

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利用率;
    ·网络节点设备的故障率;
    ·网络延时统计;
    ·带宽统计利用率等。
    --对历史统计数据的分析功能。
    --优化网络性能,xx网络中的瓶颈,实现网络流量的均匀分布。
    --提供手工设置性能的功能,如流量、压缩方法等。
11.5.3 故障管理
    故障管理具有下列功能:
    --生成错误日志,对日志进行维护并形成故障统计;
    --针对错误检测报告作出反应;
    --跟踪、辨认错误;
    --执行诊断测试;
    --手动或者自动纠正错误、排除故障等。
11.5.4 安全管理
安全管理应包括数据安全和系统安全,具有如下功能:
--系统安全
网管系统采取高级别、多层次的安全防护措施;
网管系统应提供严格的操作控制和存取控制;
自动记录非法信息,并将系统的状态自动记录,以便系统出现安全问题时能够容易地找到原因。
--数据安全
对各种配置数据、统计数据采取备份、保护措施;
采用多级别的方法,备份用户数据。
--人工或手工修复
当网络系统出现故障时,能自动及人工恢复正常工作,不影响网络的正常运行等。
11.5.5业务管理
a)用户数据管理
主要包括:
--用户数据的录入(增);
--用户数据的删除(删);
--用户数据的修改(改);
--用户数据的查询(检索)。
b)网关数据的管理
主要功能包括:
--网关数据的录入(增);
--网关数据的删除(删);
--网关数据的修改(改);
--网关数据的查询(检索)。
    c)统计
    统计的内容主要有:
    --呼叫频度;
    --有效呼叫数;
    --呼损率;
    --通话中断频度;
    --接通率;
    --各向平均时延;
    --网络通信量(流量和流向);
    --不同目的的用户使用次数;
    --用户平均每一次使用时长。
12 IP电话/传真网络的主要设备及功能
    IP电话/传真网络除IP网外主要由六大部分组成,它们是网关、网守、受理终端、计费/认证中心、结算中心和网管。
12.1 网关
    网关是跨接在电路交换网和IP网之间的设备,它的主要功能为:
    --完成PSTN、ISDN、GSM侧的呼叫建立和释放,以及IP网络侧的呼叫建立和释放。
    --完成语音编码和打包、回声xx、静音检测并提供收端缓存等功能。
    --完成语音编码方式的转换和信令协议的转换。
    --能够在通话开始时采集计费信息,并在通话结束时或定期向计费/认证中心传送计费信息。
    --能够自动识别语音、传真业务。
    --实现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是网关向网守发送的用户接入认证、地址解析和修改密码请求消息,在非标准参数中我们添加了三项,{dy}为主叫控制方式,适用于主叫号码用户,第二为卡控制方式,对应于它分为三步,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 Value为0,则网关需要在同一条IRR消息中报告所有呼叫的状态信息。CallRferenceValue为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 {dj0}网守间消息
13. 1.2. 1业务请求( Service Request)
{dj0}网守间建立业务关联关系的请求。
13. 1.2 业务确认( Service Confirmation)
    收到业务请求的{dj0}网守对 SerVice Request的确认回答。
13.1.2.3 业务拒绝(Service Rgection)
    {dj0}网守对 Service Request的拒绝回答,并给出拒绝原因。
13.1.2.4 描述器ID请求( DescriptorI DRequest)
    {dj0}网守向别的{dj0}网守请求描述器ID的请求。
13.1.2.5 描述器ID确认( Descnptor IDConfirmation)
    {dj0}网守对Descriptorl DRequest消息的确认回答,并给出该{dj0}网守的描述器ID列表。
13.1.2.6 描述器ID拒绝(Descnptor IDRejection)
    {dj0}网守对 Descriptor IDRequest消息的拒绝回答,并给出拒绝原因。
13.1.2.7 描述器请求( Descriptor Request)
    {dj0}网守向另一个{dj0}网守请求特定描述器的内容。
13. 1.2.8 描述器确认( Descriptor Confirmation)
    {dj0}网守对Descriptor Request的确认回答,并给出描述器的具体内容。
13. 1.2.9 描述器拒绝( Descriptor Rejection)
    {dj0}网守对 Descriptor Request的拒绝回答,并给出拒绝原因。
13.1.2.10 地址解析请求(AccessRequest)
    {dj0}网守间的地址解析请求。
13. 1.2.11 地址解析确认( Access Confimatlon)
    {dj0}网守对地址解析请求的确认回答。
13. 1.2. 12 地址解析拒绝( Access RCJectlon)
    {dj0}网守对地址解析请求的拒绝回答。
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 Capability 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 国际呼叫建立流程
    国际呼叫需要经过{dj0}网守进行呼叫建立。
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) 网关1向网关2发送Rlease complete消息;
    5) 网关2挂断被叫;
    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 {dj0}网守之间进行描述器交换流程



郑重声明:资讯 【IP电话、IP传真业务总体技术要求(下)_Offt的空间_百度空间】由 发布,版权归原作者及其所在单位,其原创性以及文中陈述文字和内容未经(企业库qiyeku.com)证实,请读者仅作参考,并请自行核实相关内容。若本文有侵犯到您的版权, 请你提供相关证明及申请并与我们联系(qiyeku # qq.com)或【在线投诉】,我们审核后将会尽快处理。
—— 相关资讯 ——