网络传真方法、接口设备及业务系统 【技术领域】
本发明涉及互联网应用技术，尤其涉及一种网络传真方法、接口设备及业务系统。
背景技术
传统的电信业务网络是封闭的，传真业务只能在电信业务网络中进行，如图1所示，传真机1可以通过PSTN网络2向另一传真机3发送传真。这种传统的封闭式网络还不能实现电信业务与互联网应用相结合的业务，以及电信业务与IT业务系统相结合的业务。随着开放电信网络业务技术的发展，一些标准组织制定了国际标准(例如Parlay/ParlayX等)来开放传统电信网络的业务能力。
以Parlay技术为例，其定义的接口是基于Corba技术实现的，这种接口十分复杂，而对于ParlayX技术来说，其定义的接口是基于WebServices技术实现的，这种接口在Parlay基础上进行了简化。虽然这两种技术均已被应用在一些其他的电信业务中，但目前还没有人提出开放传真业务的有关定义和网络实现。
【发明内容】
本发明的目的是提出一种网络传真方法、接口设备及业务系统，能够弥补传统传真方式的网络限制，将传真业务扩展到互联网的应用中，满足企业用户及互联网用户的多样化需求。
为实现上述目的，本发明提供了一种网络传真方法，包括：
根据应用服务器通过传真发送接口发送的传真请求，对应用服务器进行鉴权，所述传真请求至少包括认证信息、主显号码、被叫号码和传真文件；
在鉴权通过后，根据所述传真请求判断被叫号码是否合法，如果合法则根据所述传真请求将主显号码、被叫号码和传真文件传送给网络传真服务器，以实现向被叫传真机发送该传真文件的功能。
进一步的，在应用服务器的鉴权通过后，还包括以下步骤：根据所述传真请求判断传真文件的实际长度是否超过预先协商的文件长度，如果超过，则拒绝该传真请求，并向所述应用服务器返回表示传真文件过大的结果。
进一步的，所述传真请求中还包括传真文件的长度参数，在应用服务器的鉴权通过后，还包括以下步骤：根据所述传真请求判断所述传真文件的实际长度与传真文件的长度参数是否一致，如果不一致，则拒绝该传真请求，并向所述应用服务器返回表示文件需要重新发送的结果。
进一步的，所述被叫号码为至少一组，在应用服务器的鉴权通过后，还包括以下步骤：根据所述传真请求判断被叫号码的组数是否超过预先协商的数量，如果超过，则拒绝该传真请求，并向所述应用服务器返回表示群发用户数过多的结果。
进一步的，在接收应用服务器通过传真发送接口发送的传真请求之前，还包括以下步骤：应用服务器接收终端侧设备上载的传真文件，并通过传真发送接口将传真请求发送给网络传真接口设备。
为实现上述目的，本发明提供了一种网络传真接口设备，包括：
传真请求接收模块，用于接收应用服务器通过传真发送接口发送的传真请求，所述传真请求至少包括认证信息、主显号码、被叫号码和传真文件；
应用服务器鉴权模块，用于根据所述传真请求对应用服务器进行鉴权；
号码合法性判断模块，用于在鉴权通过后，根据所述传真请求判断被叫号码是否合法；
传真请求发送模块，用于在判断被叫号码合法时，根据所述传真请求将主显号码、被叫号码和传真文件传送给网络传真服务器，以实现向被叫传真机发送该传真文件的功能。
进一步的，至少包括以下模块之一：
文件长度判断模块，用于在应用服务器的鉴权通过后，根据所述传真请求判断传真文件的实际长度是否超过预先协商的文件长度，如果超过，则拒绝该传真请求，并向所述应用服务器返回表示传真文件过大的结果；
文件长度一致性判断模块，用于在应用服务器的鉴权通过后，当所述传真请求中还包括传真文件的长度参数的情况下，根据所述传真请求判断所述传真文件的实际长度与传真文件的长度参数是否一致，如果不一致，则拒绝该传真请求，并向所述应用服务器返回表示文件需要重新发送的结果；
被叫号码组数判断模块，用于在应用服务器的鉴权通过后，当所述被叫号码为至少一组的情况下，根据所述传真请求判断被叫号码的组数是否超过预先协商的数量，如果超过，则拒绝该传真请求，并向所述应用服务器返回表示群发用户数过多的结果。
为实现上述目地，本发明提供了一种包括上述网络传真接口设备的网络传真业务系统，还包括：
应用服务器，用于接收终端侧设备上载的传真文件，并通过传真发送接口将传真请求发送给所述网络传真接口设备；
网络传真服务器，用于向被叫传真机发送传真。
为实现上述目的，本发明还提供了另一种网络传真方法，包括：
网络传真服务器将传真请求发送给网络传真接口设备，所述传真请求中至少包括收到的传真文件、主叫号码和被叫号码；
网络传真接口设备根据所述被叫号码查询对应的应用服务器，并通过传真通知接收接口向所述应用服务器推送所述传真请求，所述传真通知接收接口的参数至少包括认证信息、主叫号码、被叫号码、传真文件及传真文件的长度参数；
所述应用服务器在鉴权通过后比较所述被叫号码与所述应用服务器中预先注册的号码是否匹配，如果匹配成功，则判断所述传真文件的实际长度是否与长度参数一致，是则将所述传真文件保存在自身存储区域或发给被叫方的终端侧设备，否则丢弃所述传真请求和/或所述传真文件。
基于上述技术方案，本发明简化了在互联网应用、IT应用嵌入网络传真业务的开发难度和工作量，弥补现有开放业务能力技术存在的不足，满足企业用户和互联网用户的多样化需求。
【附图说明】
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1为现有网络传真业务系统的结构示意图。
图2为本发明网络传真业务系统的一实施例的结构示意图。
图3为本发明网络传真方法的一实施例的流程示意图。
图4为本发明网络传真方法的另一实施例的流程示意图。
图5为本发明网络传真方法的再一实施例的流程示意图。
图6为本发明网络传真接口设备的一实施例的结构示意图。
图7为本发明网络传真接口设备的另一实施例的结构示意图。
【具体实施方式】
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
如图2所示，为本发明网络传真业务系统的一实施例的结构示意图。网络传真业务系统主要涉及的网元实体包括网络传真服务器4、网络传真接口设备5以及第三方应用服务器6。其中网络传真服务器4是网络传真业务的实现载体，其与电信网络2(例如软交换网络或PTSN网络等)通过信令协议交互，完成对网络传真业务的控制。网络传真接口设备5是网络传真服务器4和第三方应用服务器6之间的中间件设备，用于实现向第三方应用服务器6开放网络传真业务的能力，以及将第三方应用服务器6的业务控制指令传递给网络传真业务服务器4。
第三方应用服务器6是企业、互联网业务提供商等提供应用逻辑的载体，在本实施例中第三方应用服务器6通过IP网络7为终端侧设备8实现了网络传真业务。
在这几个网元实体中，网络传真接口设备5可以通过以WebServices技术定义的接口实现第三方应用服务器6对网络传真业务的控制。这里给出了几个接口参数的例子以利于理解。
首先考虑从第三方应用服务器6发起到网络传真接口设备5的调用的接口，例如sendFax接口(传真发送接口)，该接口用于请求发送一个传真文件到指定地址或地址集合。
sendFax接口的输入参数如下表：
参数 类型 描述 APPContext APPContext 传真的认证，包括APPID、 HashCode和timestamp(时间 戳) DestinationAddresses xsd:anyURI [0..unbounded] 传真要被发送到的地址。格式 为fax:XXXXXXXX 群发传真的最大数量可为254。 SenderAddresses xsd:anyURI 传真发送者。格式为 fax:XXXXXXXX FaxFile xsd:binary[] 需传真的tiff格式文件内容。 FaxLength xsd:int 传真的tiff格式文件的大小。
输出参数为：
参数 类型 描述 Result SendFaxResult[] 传真发送结果及计费依赖信息
SendFaxResult的数据类型可以为结构，如下表举例：
名称 类型 描述 RequestIdentifier xsd:string 请求号，传真发送请求的唯一标识。 ResultCode xsd:int 发送结果，空串表示成功。
业务接收： -1--已经受理 0--发送成功 1--系统错误，请联系管理员 2--不合法的输入值.电话号码位数不够 等 3--传真文件格式错误 4--群发用户数过多 5-主叫/被叫用户没有开通传真业务 6--用户处在暂停态等 7--用户没有权限 8--传真文件过程中出现严重错误 9--传真文件需要重新发送 10--传真文件过大
再举一个由网络传真接口设备5发起的向第三方应用服务器6发送结果的notifyFaxDeliveryStatus接口(传真传送状态通知接口)的例子，输入参数如下表：
参数 类型 描述 Result FaxDeliveryStatus 传真发送结果
FaxDeliveryStatus的数据类型可以为结构，如下表举例：
名称 类型 描述 RequestIdentifier xsd:string 请求号，传真发送请求的唯一标识。 ResultCode xsd:int 0-传送成功 101-目标用户不可达 102-目标用户挂机 103-目标用户忙音 BillingRecordFax BillingRecordFax 预留扩展字段，本次操作的详细信息
BillingRecordFax的数据类型也可以为结构，如下表举例：
名称 类型 描述 startTime xsd:string 传真开始时间
endTime xsd:string 传真结束时间 billingType xsd:string 话单类型(传真为“fax”) sendStatus xsd:string 发送状态(0：成功) failureReason xsd:string 发送失败原因(null：成功) callingNumber xsd:string 呼叫号码 calledNumber xsd:string 被叫号码 timeGap xsd:string 传真发送时长 fileName xsd:string 传真文件名称 requestID xsd:string 请求号 triggerTimes xsd:string 重发次数
该notifyFaxDeliveryStatus接口无输出参数。
再举一个由网络传真接口设备5将传真推送给应用的notifyFaxReception接口(传真接收通知接口)的例子，输入参数如下表：
参数 类型 描述 APPContext APPContext 详细见公共数据结构 SenderAddress xsd:anyURI 传真发送者，格式为 fax:XXXXXXXX DestinationAddresses xsd:anyURI 客户端用来接收传真的目标 地址(接收传真的地址)。 格式为fax:XXXXXXXX FaxFile xsd:binary[] 需传真的tiff格式文件。 FaxLength xsd:int 传真的tiff格式文件的大小。
该notifyFaxReception接口无输出参数。
接下来通过一个实施例对网络传真的业务流程进行介绍。如图3所示，为本发明网络传真方法的一实施例的流程示意图。在本实施例中，用户可以利用终端侧设备在第三方应用服务器上申请网络传真业务，并获得网络传真号码(例如PSTN号码或特服号等方式)，在进行传真前，用户一般需要先通过第三方应用服务器的用户身份认证才能使用该业务。
第三方应用服务器可以通过浏览器或客户端等方式将网络传真业务功能展现给用户，当用户选择使用网络传真业务时，通过终端侧设备上载要发送的传真文件，并选择被叫号码来发送网络传真的指令。
第三方应用服务器通过传真发送接口将传真请求发送给网络传真接口设备，网络传真接口设备的处理流程如下：
步骤101、根据应用服务器通过传真发送接口发送的传真请求，对应用服务器进行鉴权，所述传真请求至少包括认证信息、主显号码、被叫号码和传真文件；
步骤102、在鉴权通过后，根据所述传真请求判断被叫号码是否合法；
步骤103，如果被叫号码合法，则执行步骤103，否则结束操作；
步骤104、根据所述传真请求将主显号码、被叫号码和传真文件传送给网络传真服务器，以实现向被叫传真机发送该传真文件的功能。
在本实施例中，网络传真接口设备在完成对第三方应用服务器身份的鉴权，以及对被叫号码的检查后，保证了网络传真业务的安全稳定的处理。网络传真服务器在接收到网络传真接口设备发送来的主显号码、被叫号码和传真文件后，就可以通过电信网络(例如软交换网络或PSTN等)向被叫传真机发送传真文件。
如图4所示，为本发明网络传真方法的另一实施例的流程示意图。通过前面对sendFax接口的描述，可以看出第三方应用服务器除了需要向网络传真接口设备发送认证信息、主显号码、被叫号码和传真文件之外，还可以传送一些与传真文件相关的参数，例如传真文件的长度参数。因此在本实施例中给出了带有长度参数的处理流程，如下：
步骤201、网络传真接口设备根据应用服务器通过传真发送接口发送的传真请求，对应用服务器进行鉴权，传真请求包括认证信息、主显号码、被叫号码、传真文件以及传真文件的长度参数。认证信息(即应用上下文APPContext)包括：应用标识APPID、哈希码HashCode和时间戳timestamp，其中APPID存储了第三方标示符，HashCode存储了对接口加密的散列码，timestamp存储了发送这个接口的时间戳。
步骤202、网络传真接口设备根据认证信息判断该应用服务器是否能够通过鉴权，是则执行步骤203，否则执行步骤202’。
步骤202’、网络传真接口设备通过sendFax接口的SendFaxResult的结果码ResultCode来拒绝该次请求，该结果码表示用户没有权限。
步骤203、网络传真接口设备计算传真文件的实际长度，并根据传真请求判断传真文件的实际长度与传真文件的长度参数是否一致，是则执行步骤204，否则执行步骤203’。
步骤203’、网络传真接口设备通过sendFax接口的SendFaxResult的结果码ResultCode来拒绝该次请求，该结果码表示文件需要重新发送。
步骤204、网络传真接口设备根据传真请求判断传真文件的实际长度是否超过预先协商的文件长度，是则执行步骤205，否则执行步骤204’。
步骤204’、网络传真接口设备通过sendFax接口的SendFaxResult的结果码ResultCode来拒绝该次请求，该结果码表示传真文件过大。
步骤205、网络传真接口设备根据传真请求中的DestinationAddresses获得被叫号码，并判断被叫号码是否是电信运营商合法的电话号码，是则执行步骤206，否则执行步骤205’。
步骤205’、网络传真接口设备通过sendFax接口的SendFaxResult的结果码ResultCode来拒绝该次请求，该结果码表示不合法的被叫号码输入值。
步骤206、被叫号码可以为一组或多组，如果被叫号码不止一组，那么网络传真接口设备会根据传真请求判断被叫号码的组数是否超过预先协商的数量，是则执行步骤206，否则执行步骤205’。
步骤206’、网络传真接口设备通过sendFax接口的SendFaxResult的结果码ResultCode来拒绝该次请求，该结果码表示群发用户数过多。
步骤207、网络传真接口设备根据传真请求将主显号码、被叫号码和传真文件传送给网络传真服务器，以实现向被叫传真机发送该传真文件的功能。网络传真接口设备在发送传真后，还可以通过传真传送状态通知接口向第三方应用服务器返回此次的传真结果，具体结果可以参考前述notifyFaxDeliveryStatus接口的参数表。第三方应用服务器接收到传真结果后，将该传真结果推送给用户的终端侧设备上。
在其他的实施例中，网络传真接口设备需要判断的内容可以有所不同，其判断的流程顺序也不必拘泥于本实施例的顺序。
如图5所示，为本发明网络传真方法的再一实施例的流程示意图。在本实施例中给出了从传真机发送传真到IP网络中的终端侧设备的过程。当传真机向网络传真用户发送传真时，电信网络(例如软交换网络或PSTN网络等)将把该请求路由至网络传真服务器，网络传真服务器和传真机之间建立话路，网络传真服务器接收传真机发过来的传真文件，接下来的步骤如下：
步骤301、网络传真服务器将传真请求发送给网络传真接口设备，所述传真请求中至少包括收到的传真文件、主叫号码和被叫号码；
步骤302、网络传真接口设备根据所述被叫号码查询对应的应用服务器，并通过传真通知接收接口向所述应用服务器推送所述传真请求，传真通知接收接口的参数至少包括认证信息、主叫号码、被叫号码、传真文件及传真文件的长度参数；
步骤303、应用服务器根据认证信息确认网络传真接口设备的身份是否符合，该鉴权过程可参考上一实施例，在鉴权通过后比较该被叫号码与应用服务器中预先注册的号码是否匹配，是则执行步骤304，否则执行步骤305；
步骤304、应用服务器判断该传真文件的实际长度是否与长度参数一致，是则执行步骤306，否则执行步骤305；
步骤305、应用服务器丢弃该传真请求和/或传真文件，并结束操作；
步骤306、应用服务器将该传真文件保存在自身存储区域，以供用户访问，或者直接发给被叫方的终端侧设备。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
如图6所示，为本发明网络传真接口设备的一实施例的结构示意图。本实施例包括：传真请求接收模块11、应用服务器鉴权模块12、号码合法性判断模块13以及传真请求发送模块14。其中传真请求接收模块11用于接收应用服务器通过传真发送接口发送的传真请求，所述传真请求至少包括认证信息、主显号码、被叫号码和传真文件。应用服务器鉴权模块12用于根据所述传真请求对应用服务器进行鉴权。号码合法性判断模块13用于在鉴权通过后，根据所述传真请求判断被叫号码是否合法。传真请求发送模块14用于在判断被叫号码合法时，根据所述传真请求将主显号码、被叫号码和传真文件传送给网络传真服务器，以实现向被叫传真机发送该传真文件的功能。
如图7所示，为本发明网络传真接口设备的另一实施例的结构示意图。与上一实施例相比，本实施例至少还包括以下模块之一：
文件长度判断模块16，用于在应用服务器的鉴权通过后，根据所述传真请求判断传真文件的实际长度是否超过预先协商的文件长度，如果超过，则拒绝该传真请求，并向所述应用服务器返回表示传真文件过大的结果；
文件长度一致性判断模块15，用于在应用服务器的鉴权通过后，当所述传真请求中还包括传真文件的长度参数的情况下，根据所述传真请求判断所述传真文件的实际长度与传真文件的长度参数是否一致，如果不一致，则拒绝该传真请求，并向所述应用服务器返回表示文件需要重新发送的结果；
被叫号码组数判断模块17，用于在应用服务器的鉴权通过后，当所述被叫号码为至少一组的情况下，根据所述传真请求判断被叫号码的组数是否超过预先协商的数量，如果超过，则拒绝该传真请求，并向所述应用服务器返回表示群发用户数过多的结果。
最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。