MISC系统短信SP接入培训

MISC系统短信SP接入培训

第一章、接口改造分册

MISC系统结构和作用

SP接入MISC流程

CMPP3.0接口开发说明

正反向订购接口开发说明

网站改造SSO接口流程说明

一、MISC系统结构和作用

1、SP接入MISC流程

组织SP培训

SP程序开发及业务梳理

安排SP在试验环境做接口测试

现网全业务申报

SP进行全业务自行拨测及相关程序调整

SP提交全业务拨测报告供计费验证

安排割接

2、SP接入MISC流程－流程说明

• 1）首先需要组织SP参与MISC升级改造培训

• 2）培训结束后SP就应该开始着手进行业务梳理及接口程序开发，并在移动要求的时间内完成这项工作

• 3）SP具备接口测试条件以后，集中统一安排在测试环境做接口测试及典型业务申报

• 4）接口测试通过以后根据现网MISC系统建设情况，安排接口测试通过的SP在现网做全业务申报和全业务拨测

• 5）全业务拨测通过后提交拨测报告供计费做计费验证

• 6）验证通过后根据网络部的割接计划安排割接

3、接口改造总体说明

• 在整个升级改造过程中“接口改造”占了一个非常重要的位置。SP需要根据CMPP3.0协议和DSMP规范对自己的接口进行改造开发，才能接入MISC。

• 接口改造主要分为以下几个方面：

1）CMPP3.0接口程序改造

2）正反向订购、取消接口开发

3）网站改造SSO接口开发

CMPP3.0接口改造说明

• 接口开发需具备条件

• CMPP2.0和CMPP3.0区别

• CMPP3.0协议包体说明

4、接口改造需具备条件

1、自己开发接口的SP，应根据CMPP3.0协议对接口进行修改；使用API的SP，应向接入网关的省公司或网关厂家索取最新的CMPP3.0接口API以及使用说明等相关文档

2、不管是自己开发接口的，还是使用接口API的SP，都应该详细了解CMPP2.0和CMPP3.0的区别

二、CMPP协议

1、CMPP2.0和CMPP3.0区别－SP登录

CMPP2.0和CMPP3.0区别－SP登录

• 1、SP向所接入的ISMG发送登录请求；

• 2、ISMG向MISC发送SP登陆鉴权信息查询请求；

• 3、MISC向ISMG返回SP登陆鉴权结果；

• 4、ISMG根据此信息进行SP登陆认证，并向SP返回认证结果；

2、CMPP2.0和CMPP3.0区别－协议包的变化

1）包内容的变化：CMPP_SUBMIT

CMPP3.0中新增字段：

Fee_terminal_type：被计费用户的号码类型，0：真实号码；1：伪码

Dest_terminal_type：接收短信的用户号码类型，0：真实号码；1：伪码

LinkID：20个字节，点播业务使用，非点播类业务的MT流程不使用该字段

CMPP3.0中删除字段：

Reserve：保留字段。

CMPP3.0中变化字段：

Fee_terminal_id：被计费用户号码。长度扩展为32个字节，数据类型从UnsignedInteger修改为OctetString

Dest_terminal_id：接收短信的用户号码。长度扩展为32个字节，数据类型从UnsignedInteger修改为OctetString

2）包内容的变化CMPP_DELIVER

CMPP3.0中新增字段：

Src_terminal_type：源终端号码类型，0：真实号码；1：伪码

LinkID：20个字节，点播业务使用，非点播类业务的MT流程不使用字段

CMPP3.0中删除字段：

Reserve：保留字段

CMPP3.0中变化字段：

Src_terminal_id：源终端号码。长度扩展为32个字节，数据类型从UnsignedInteger修改为OctetString

字段说明：

伪码：一个随机字符串，对于一个SP，唯一标识一个用户

LinkID：20位字符串，该字段的值由MISC产生，编码格式为4位MISCID+12位时间+4位序列号。用于点播类业务中MT与MO消息的匹配。

3、CMPP3.0协议包体说明CMPP_SUBMIT

字段名	字节数	属性	描述
Msg_Id	8	UnsignedInteger	信息标识
Pk_total	1	UnsignedInteger	相同Msg_Id的信息总条数，从1开始。
Pk_number	1	UnsignedInteger	相同Msg_Id的信息序号，从1开始。
Registered_Delivery	1	UnsignedInteger	是否要求返回状态确认报告： 0：不需要； 1：需要。
Msg_level	1	UnsignedInteger	信息级别。
Service_Id	10	OctetString	业务标识，是数字、字母和符号的组合。
Fee_UserType	1	UnsignedInteger	计费用户类型字段： 0：对目的终端MSISDN计费； 1：对源终端MSISDN计费； 2：对SP计费； 3：表示本字段无效，对谁计费参见Fee_terminal_Id字段。
Fee_terminal_Id	32	OctetString	被计费用户的号码，当Fee_UserType为3时该值有效，当Fee_UserType为0、1、2时该值无意义。
Fee_terminal_type	1	UnsignedInteger	被计费用户的号码类型，0：真实号码；1：伪码。
TP_pId	1	UnsignedInteger	GSM协议类型。详细是解释请参考GSM03.40中的9.2.3.9。
TP_udhi	1	UnsignedInteger	GSM协议类型。详细是解释请参考GSM03.40中的9.2.3.23,仅使用1位，右对齐。
Msg_Fmt	1	UnsignedInteger	信息格式： 0：ASCII串； 3：短信写卡操作； 4：二进制信息； 8：UCS2编码； 15：含GB汉字。。。。。。
Msg_src	6	OctetString	信息内容来源(SP_Id)。
FeeType	2	OctetString	资费类别： 01：对“计费用户号码”免费； 02：对“计费用户号码”按条计信息费； 03：对“计费用户号码”按包月收取信息费。
FeeCode	6	OctetString	资费代码（以分为单位）。
ValId_Time	17	OctetString	存活有效期，格式遵循SMPP3.3协议。
At_Time	17	OctetString	定时发送时间，格式遵循SMPP3.3协议。
Src_Id	21	OctetString	源号码。SP的服务代码或前缀为服务代码的长号码,网关将该号码完整的填到SMPP协议Submit_SM消息相应的source_addr字段，该号码最终在用户手机上显示为短消息的主叫号码。
DestUsr_tl	1	UnsignedInteger	接收信息的用户数量(小于100个用户)。
Dest_terminal_Id	32*DestUsr_tl	OctetString	接收短信的MSISDN号码。
Dest_terminal_type	1	UnsignedInteger	接收短信的用户的号码类型，0：真实号码；1：伪码。
Msg_Length	1	UnsignedInteger	信息长度(Msg_Fmt值为0时：<160个字节；其它<=140个字节)，取值大于或等于0。
Msg_Content	Msg_length	OctetString	信息内容。
LinkID	20	OctetString	点播业务使用的LinkID，非点播类业务的MT流程不使用该字段。

4、CMPP3.0协议包体说明CMPP_SUBMIT_RESP

字段名

字节数

属性

描述

Msg_Id

UnsignedInteger

信息标识，生成算法如下：

采用64位（8字节）的整数：

时间（格式为MMDDHHMMSS，即月日时分秒）：bit64~bit39，其中

bit64~bit61：月份的二进制表示；

bit60~bit56：日的二进制表示；

bit55~bit51：小时的二进制表示；

bit50~bit45：分的二进制表示；

bit44~bit39：秒的二进制表示；

短信网关代码：bit38~bit17，把短信网关的代码转换为整数填写到该字段中；
序列号：bit16~bit1，顺序增加，步长为1，循环使用。

各部分如不能填满，左补零，右对齐。

（SP根据请求和应答消息的Sequence_Id一致性就可得到CMPP_Submit消息的Msg_Id）

Result

UnsignedInteger

结果：

0：正确；

1：消息结构错；

2：命令字错；

3：消息序号重复；

4：消息长度错；

5：资费代码错；

6：超过最大信息长；

7：业务代码错；

8：流量控制错；

9：本网关不负责服务此计费号码；

10：Src_Id错误；

11：Msg_src错误；

12：Fee_terminal_Id错误；

13：Dest_terminal_Id错误；

……

5、CMPP3.0协议包体说明CMPP_DELIVER

字段名	字节数	属性	描述
Msg_Id	8	UnsignedInteger	信息标识。生成算法如下：采用64位（8字节）的整数：时间（格式为MMDDHHMMSS，即月日时分秒）：bit64~bit39，其中 bit64~bit61：月份的二进制表示； bit60~bit56：日的二进制表示； bit55~bit51：小时的二进制表示； bit50~bit45：分的二进制表示； bit44~bit39：秒的二进制表示； 1.短信网关代码：bit38~bit17，把短信网关的代码转换为整数填写到该字段中；序列号：bit16~bit1，顺序增加，步长为1，循环使用。各部分如不能填满，左补零，右对齐。
Dest_Id	21	OctetString	目的号码。 SP的服务代码，一般4--6位，或者是前缀为服务代码的长号码；该号码是手机用户短消息的被叫号码。
Service_Id	10	OctetString	业务标识，是数字、字母和符号的组合。
TP_pid	1	UnsignedInteger	GSM协议类型。详细解释请参考GSM03.40中的9.2.3.9。
TP_udhi	1	UnsignedInteger	GSM协议类型。详细解释请参考GSM03.40中的9.2.3.23，仅使用1位，右对齐。
Msg_Fmt	1	UnsignedInteger	信息格式： 0：ASCII串； 3：短信写卡操作； 4：二进制信息； 8：UCS2编码； 15：含GB汉字。
Src_terminal_Id	32	OctetString	源终端MSISDN号码（状态报告时填为CMPP_SUBMIT 消息的目的终端号码）。
Src_terminal_type	1	UnsignedInteger	源终端号码类型，0：真实号码；1：伪码。
Registered_Delivery	1	UnsignedInteger	是否为状态报告： 0：非状态报告； 1：状态报告。
Msg_Length	1	UnsignedInteger	消息长度，取值大于或等于0。
Msg_Content	Msg_length	OctetString	消息内容。
LinkID	20	OctetString	点播业务使用的LinkID，非点播类业务的MT流程不使用该字段。

6、CMPP3.0协议包体说明CMPP_DELIVER_RESP

字段名	字节数	属性	描述
Msg_Id	8	UnsignedInteger	信息标识（CMPP_DELIVER中的Msg_Id字段）。
Result	4	UnsignedInteger	结果： 0：正确； 1：消息结构错； 2：命令字错； 3：消息序号重复； 4：消息长度错； 5：资费代码错； 6：超过最大信息长； 7：业务代码错； 8:流量控制错； 9~：其他错误。

7、CMPP3.0协议包体说明_网关返回状态报告

字段名	字节数	属性	描述
Msg_Id	8	UnsignedInteger	信息标识。 SP提交短信（CMPP_SUBMIT）操作时，与SP相连的ISMG产生的Msg_Id。
Stat	7	OctetString	发送短信的应答结果，含义详见表一。SP根据该字段确定CMPP_SUBMIT消息的处理状态。
Submit_time	10	OctetString	YYMMDDHHMM（YY为年的后两位00-99，MM： 01-12，DD：01-31，HH：00-23，MM：00-59）。
Done_time	10	OctetString	YYMMDDHHMM。
Dest_terminal_Id	32	OctetString	目的终端MSISDN号码(SP发送CMPP_SUBMIT消息的目标终端)。
SMSC_sequence	4	UnsignedInteger	取自SMSC发送状态报告的消息体中的消息标识。

8、CMPP3.0协议包体说明_返回状态报告值

MessageState	FinalMessageStates	Description
DELIVERED	DELIVRD	Messageisdeliveredtodestination
EXPIRED	EXPIRED	Messagevalidityperiodhas expired
DELETED	DELETED	Messagehasbeendeleted.
UNDELIVERABLE	UNDELIV	Messageisundeliverable
ACCEPTED	ACCEPTD	Messageisinacceptedstate(i.e.hasbeenmanuallyreadonbehalf ofthesubscriberbycustomerservice)
UNKNOWN	UNKNOWN	Messageisininvalidstate
REJECTED	REJECTD	Messageisinarejectedstate
MA:xxxx	MA:xxxx	SMSC不返回响应消息时的状态报告
MB:xxxx	MB:xxxx	SMSC返回错误响应消息时的状态报告
MC:xxxx	MC:xxxx	没有从SMSC处接收到状态报告时的状态报告
CA:xxxx	CA:xxxx	SCP不返回响应消息时的状态报告
CB:xxxx	CB:xxxx	SCP返回错误响应消息时的状态报告
DA:xxxx	DA:xxxx	DSMP不返回响应消息时的状态报告
DB:xxxx	DB:xxxx	DSMP返回错误响应消息时的状态报告
SA:xxxx	SA:xxxx	SP不返回响应消息时的状态报告
SB:xxxx	SB:xxxx	SP返回错误响应消息时的状态报告
IA:xxxx	IA:xxxx	下一级ISMG不返回响应消息时的状态报告
IB:xxxx	IB:xxxx	下一级ISMG返回错误响应消息时的状态报告
IC:xxxx	IC:xxxx	没有从下一级ISMG处接收到状态报告时的状态报告

9、MISC常见错误代码说明

错误代码	错误描述	备注
101	手机号码错误	MT包中的计费号码或者接收号码不是梦网用户
102	用户停机	䦋㌌㏒㧀좈໱琰茞ᓀ㵂Ü
103	用户欠费	䦋㌌㏒㧀좈໱琰茞ᓀ㵂Ü
107	业务不存在	MT包中的Service_Id与SP在MISC中申报的业务代码不一致
108	业务暂停	MT包中所填的业务在MISC中已被暂停
115	用户没有订购此业务	SP向未订购该业务的用户下发MT消息
116	用户暂停此业务	SP向已暂停该业务的用户下发MT消息
140	用户没有点播该业务	点播类业务对应的MT中，业务代码、LINKID和MO中的不匹配

三、PROVISION接口

正、反向接口开发说明

• 正向同步PROVISION接口规范

• 正向同步PROVISION接口消息定义

• 正向订购、取消包示例

• 反向接口规范

• 反向订购接口消息定义

• 反向取消接口消息定义

• 反向订购、取消包示例

1、正向同步PROVISION接口规范－流程图

2、正向同步PROVISION接口规范－流程说明

• 用户通过手机发送定制或取消指令到相应的SP特服号，网关收到MO消息后向MISC发起MO鉴权批价请求，MISC收到MO鉴权批价请求后进行订购、取消点播指令匹配；如果判断指令是定制或取消指令，则MISC会向SP发送订购关系同步请求包SyncOrderRelationReq

• 用户通过WWW网站发起订购或取消请求，MISC在收到WWW网站的请求之后，会向SP发送订购关系同步请求包SyncOrderRelationReq

• SP收到同步请求包后，对订购请求做相应的订购关系处理，并返回订购关系同步应答SyncOrderRelationResp

• MISC收到应答包后，根据返回结果是否正确，在系统中生成正式的订购关系或者取消订购关系，并由1862系统给用户下发订购成功或取消成功的提醒消息

•

3、正向同步PROVISION接口消息定义

• 功能描述

此接口在MISC因为某种情况更新了用户订购关系（包括订购、取消、暂停、激活）的时候，通过此接口发起和SP的更新订购关系的交互。

消息名	消息类型	消息方向
SyncOrderRelationReq	Request	MISCàSP
SyncOrderRelationResp	Response	SPàMISC

• 接口内容描述

SyncOrderRelationReq消息字段描述：

返回定义	重要性	类型	说明
MsgType	必须	string	消息类型
TransactionID	必须	string	该消息编号
Version	必须	string	该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0”
Send_Address	必须	address_info_schema	发送方的地址
Dest_Address	必须	address_info_schema	接收方的地址
FeeUser_ID	必须	user_id_schema	计费用户标识
DestUser_ID	必须	user_id_schema	使用用户标识
LinkID	可选	string	临时订购关系的事务ID
ActionID	必须	integer	服务状态管理动作代码，具体值如下： 1：开通服务； 2：停止服务； 3：激活服务； 4：暂停服务；
ActionReasonID	必须	integer	产生服务状态管理动作原因的代码，具体值如下： 1：用户发起行为 2：Admin&1860发起行为 3：Boss停机 4：Boss开机 5：Boss过户 6：Boss销户 7：Boss改号 8：扣费失败导致的服务取消 9：其他
SPID	可选	string	SP的企业代码
SPServiceID	必须	string	SP中该服务的服务代码
AccessMode	可选	Integer	服务的访问方式 1：WEB 2：WAP 3：SMS
FeatureStr	可选	binary	服务订购参数（base64加密），内容是长号码＋空格＋用户发送内容

address_info_schema(地址信息)描述

字段名称

字段类型

字段描述

DeviceType

integer

设备类型

0：MISC

100：ISMG

101：WAP SP PROXY

1XX：其他业务网关

200：WAP PORTAL

201：WWW PORTAL

202：VOICE PORTAL

203：PDA PORTAL

2XX：其他门户

300：MMSC

301：KJAVA SERVER

302：LSP

3XX：其它应用平台

400：SP

DeviceID

string

设备编号，设备编号采用各设备的入网编号，例如短信网关使用网关ID、对SP使用其企业代码，该设备编号由MISC分配，并且在同一设备类型中该编号唯一

user_id_schema(用户标识)描述

字段名称

字段类型

字段描述

UserIDType

integer

用户标识类型

1：用手机号标识

2：用伪码标识

3：两者同时标识

MSISDN

string

用户手机号

PseudoCode

binary

用户伪码

4、正向同步接口应答包消息定义

SyncOrderRelationResp消息字段描述：

字段名	重要性	类型	说明
MsgType	必须	string	消息类型
TransactionID	必须	string	该消息编号
Version	必须	string	该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0”
hRet	必须	integer	返回值，主要错误如下： 0：成功 4007：MISC同步开通服务,但SP端已存在订购关系,且状态为开通 4008：MISC同步开通服务,且SP端不存在订购关系,但开通服务失败 4010：MISC同步停止服务,且SP端存在订购关系,但取消服务失败 4011：MISC同步停止服务,但SP端不存在订购关系 4012：MISC同步暂停服务,且SP端存在订购关系,但暂停服务失败 4013：MISC同步暂停服务,但SP端不存在订购关系 4015：MISC同步激活服务,但SP端已存在订购关系,且状态为开通 4016：MISC同步激活服务,但SP端不存在订购关系其它错误请参见《MISC系统短信SP接入指南－接口改造分册》。

5、正向订购、取消包示例

正向订购请求包

<?xmlversion="1.0"encoding="utf-8"?>

<SOAP-ENV:Envelopexmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>

<TransactionIDxmlns="http://www.monternet.com/dsmp/schemas/">00230301659556</TransactionID>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<SyncOrderRelationReqxmlns="http://www.monternet.com/dsmp/schemas/"><Version>1.5.0</Version>

<MsgType>SyncOrderRelationReq</MsgType>

<Send_Address>

<DeviceType>0</DeviceType>

<DeviceID>0023</DeviceID>

</Send_Address>

<Dest_Address>

</Dest_Address>

<FeeUser_ID>

</FeeUser_ID>

<DestUser_ID>

</DestUser_ID>

<ActionID>1</ActionID>

<FeatureStr>YWJjZGVm</FeatureStr>

</SyncOrderRelationReq>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

正向取消请求包

<?xmlversion="1.0"encoding="utf-8"?>

<SOAP-ENV:Envelopexmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>

<TransactionIDxmlns="http://www.monternet.com/dsmp/schemas/">00230301659556</TransactionID>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<SyncOrderRelationReqxmlns="http://www.monternet.com/dsmp/schemas/"><Version>1.5.0</Version>

<MsgType>SyncOrderRelationReq</MsgType>

<Send_Address>

<DeviceType>0</DeviceType>

<DeviceID>0023</DeviceID>

</Send_Address>

<Dest_Address>

</Dest_Address>

<FeeUser_ID>

</FeeUser_ID>

<DestUser_ID>

</DestUser_ID>

<ActionID>2</ActionID>

<FeatureStr>YWJjZGVm</FeatureStr>

</SyncOrderRelationReq>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

6、反向订购接口规范－流程图

7、反向订购接口规范－流程说明

1）SP代替用户，向MISC发起反向订购请求SubscribeServiceReq

并等待MISC处理

2）MISC对消息中的来源地址、企业代码进行鉴权，判断是否允许

该SP进行反向订购

3）接入鉴权成功后，再进行用户鉴权和订购关系鉴权，判断用户状

态是否正确以及是否是重复订购等

4）上面鉴权成功后，MISC向SP发送订购关系同步请求包

SyncOrderRelationReq

5）SP收到同步请求后，对订购请求做相应的订购关系处理，并返

回订购关系同步应答SyncOrderRelationResp

6）MISC收到应答后，判断应答值是否为0。如果应答值为0，则在

MISC中生成正式的订购关系，并给SP返回成功的反向订购处理响应包

SubscribeServiceResp；如果应答值不为0，则不生成订购关系，同时

给SP返回不成功的反向订购应答包SubscribeServiceResp

7）SP如果收到MISC的错误响应，则说明订购失败，SP必须对这个失

败消息做相应处理，比如把自己先生成的订购关系清除掉等等

8）如果收到MISC的正确响应，则SP可以不做任何处理

8、反向订购接口消息定义

• 功能描述

此接口用于用户通过SP订购数据业务的时候，SP先进行业务关系订购，再通过该接口向MISC进行用户服务订购同步的请求。

消息名	消息类型	消息方向
SubscribeServiceReq	Request	SPàMISC
SubscribeServiceResp	Response	MISCàSP

SubscribeServiceReq消息字段描述：

字段名	重要性	类型	说明
MsgType	必须	string	消息类型
TransactionID	必须	string	该消息编号（长度不能超过16位）
Version	必须	string	该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0”
Send_Address	必须	address_info_schema	发送方的地址
Dest_Address	必须	address_info_schema	接收方的地址
FeeUser_ID	必须	user_id_schema	计费用户标识
DestUser_ID	必须	user_id_schema	使用用户标识当计费用户和使用用户为同个用户的时候， FeeUser_ID和DestUser_ID的值为相同，否则填为不同的用户
Service_ID	必须	service_id_schema	服务标识
FeatureStr	可选	binary	订购特征参数，订购业务需要携带的参数，可以携带文本/多媒体的相关信息

反向订购应答接口消息定义

SubscribeServiceResp消息字段描述：

字段名	重要性	类型	说明
MsgType	必须	string	消息类型
TransactionID	必须	string	该消息编号
Version	必须	string	该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0”
hRet	必须	integer	返回值,见第9章的定义，如果返回成功，则下面几个参数必须存在，否则是可选的
LinkID	条件	string	临时订购关系的匹配码，用来鉴权一次点播请求等事务性的业务。当MISC生成的订购关系为临时订购关系的时候，返回本字段，否则不填本字段。

9、反向取消接口规范－流程图

10、反向取消接口规范－流程说明

1）SP代替用户，向MISC发起反向取消请求UnSubscribeServiceReq

并等待MISC处理

2）MISC对消息中的来源地址、企业代码进行鉴权，判断是否允许

该SP进行反向取消

3）接入鉴权成功后，再进行用户鉴权和订购关系鉴权，判断用户状

态是否正确以及是否存在订购关系

4）上面鉴权成功后，MISC向SP发送订购关系同步请求包

SyncOrderRelationReq

5）SP收到同步请求后，对订购请求做相应的取消处理，并返

回订购关系同步应答SyncOrderRelationResp

6）MISC收到应答后，判断应答值是否为0。如果应答值为0，则在

MISC中取消订购关系，并给SP返回成功的反向取消处理应答包

UnSubscribeServiceResp；如果应答值不为0，则不取消订购关系，同

时给SP返回不成功的反向取消应答包UnSubscribeServiceResp

7）SP如果收到MISC的错误响应，则说明取消失败，SP必须对这个失

败消息做相应处理，比如把已取消的订购关系恢复等等。

8）如果收到MISC的正确响应，则SP可以不做任何处理

11、反向取消接口消息定义

• 功能描述

此接口用于用户通过SP取消已订购的数据业务的时候，SP先通过该接口向MISC进行用户取消服务订购的请求。MISC进行取消服务订购成功后，SP才取消用户对应的业务订购关系。

消息名	消息类型	消息方向
UnSubscribeServiceReq	Request	SPàMISC
UnSubscribeServiceResp	Response	MISCàSP

• 接口内容描述

UnSubscribeServiceReq消息字段描述：

字段名	重要性	类型	说明
MsgType	必须	string	消息类型
TransactionID	必须	string	该消息编号（不能超过16位）
Version	必须	string	该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0”
Send_Address	必须	address_info_schema	发送方的地址
Dest_Address	必须	address_info_schema	接收方的地址
FeeUser_ID	必须	user_id_schema	计费用户标识
DestUser_ID	必须	user_id_schema	使用用户标识当使用用户和计费用户为同一用户的时候， FeeUser_ID和DestUser_ID的值相同。
Service_ID	必须	service_id_schema	服务标识

UnSubscribeServiceResp消息字段描述：

字段名	重要性	类型	说明
MsgType	必须	string	消息类型
TransactionID	必须	string	该消息编号
Version	必须	string	该接口消息的版本号，本次所有的接口消息的版本都为“1.5.0”
hRet	必须	integer	返回值。具体定义请参见《MISC系统短信SP接入指南－接口改造分册》

12、反向订购、取消包示例

SP反向订购请求包

<?xmlversion="1.0"encoding="UTF-8"?>

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"xmlns="http://www.monternet.com/dsmp/schemas/">

<SOAP-ENV:Header>

<TransactionIDxmlns="http://www.monternet.com/dsmp/schemas/"xsi:type="xsd:string">9130020301801050</TransactionID>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<SubscribeServiceReqxmlns="http://www.monternet.com/dsmp/schemas/">

<MsgType>SubscribeServiceReq</MsgType>

<Send_Address>

<DeviceType>400</DeviceType>

<DeviceID>913002</DeviceID>

</Send_Address>

<Dest_Address>

<DeviceType>0</DeviceType>

<DeviceID>0023</DeviceID>

</Dest_Address>

<FeeUser_ID>

</FeeUser_ID>

<DestUser_ID>

</DestUser_ID>

<Service_ID>

<SPServiceID>-TQAAU</SPServiceID>

</Service_ID>

</SubscribeServiceReq>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

反向订购应答包

<?xmlversion="1.0"encoding="UTF-8"?>

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">

<SOAP-ENV:Header>

<dsmp:TransactionIDxmlns:dsmp="http://www.monternet.com/dsmp/schemas/">9130020301801050</dsmp:TransactionID>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<SubscribeServiceRespxmlns="http://10.1.2.122/misc/dsmp.xsd">

<MsgType>SubscribeServiceResp</MsgType>

<hRet>0</hRet>

</SubscribeServiceResp>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

反向取消请求包

<?xmlversion="1.0"encoding="UTF-8"?>

<SOAP-ENV:Header>

<TransactionIDxmlns="http://www.monternet.com/dsmp/schemas/"xsi:type="xsd:string">9130020301801050</TransactionID>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<UnSubscribeServiceReqxmlns="http://www.monternet.com/dsmp/schemas/">

<MsgType>UnSubscribeServiceReq</MsgType>

<Send_Address>

<DeviceType>400</DeviceType>

<DeviceID>913002</DeviceID>

</Send_Address>

<Dest_Address>

<DeviceType>0</DeviceType>

<DeviceID>0023</DeviceID>

</Dest_Address>

<FeeUser_ID>

</FeeUser_ID>

<DestUser_ID>

</DestUser_ID>

<Service_ID>

<SPServiceID>-TQAAU</SPServiceID>

</Service_ID>

</UnSubscribeServiceReq>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

反向取消应答包

<?xmlversion="1.0"encoding="UTF-8"?>

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">

<SOAP-ENV:Header>

<dsmp:TransactionIDxmlns:dsmp="http://www.monternet.com/dsmp/schemas/">9130020301801050</dsmp:TransactionID>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<UnSubscribeServiceRespxmlns="http://10.1.2.122/misc/dsmp.xsd">

<MsgType>UnSubscribeServiceResp</MsgType>

<hRet>0</hRet>

</UnSubscribeServiceResp>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

四、网站SSO接口

网站改造SSO流程

• 用户在SSO统一登录框中登录的处理流程

• 用户在SP网站上进行登录的处理流程

• 用户在整个梦网平台上签退的处理流程

• 用户订购业务与点播下载业务的处理流程

1、用户在中央SSO的iframe页面上登录

统一登录页面登录

点击登录

输入手机号码和梦网密码

点击登录

输入页面附加码

登录成功

2、用户在SP网站上进行登录的处理流程

由于在MISC平台和SSO平台的实施过程中，会存在由SP网站直接向业务接入地的SSO发起本地用户鉴权请求的情况，所以需要SSO平台向SP提供用户登录鉴权的功能。

3、SSO登录接口定义

用户登录接口

接口名称	SPLogon
接口描述	中央SSO平台向SP系统开放的用户登录功能接口，实现用户登录功能。
接口协议	HTTPS协议
接口方向	请求：SPà中央SSO平台响应：中央SSO平台àSP

用户登录接口响应的参数描述：

响应中的BackURL上以[BackURL]?[参数名称1]=[参数值1]&[参数名称2]=[参数值2]的形式返回以下输出参数：

字段名称	字段说明
ResultID	SSO平台处理的结果，0表示成功，其它表示失败。失败时不返回RandomSessionKey字段
ResultString	ResultIDid为0时，内容为”OK” 失败时将在本字段表示具体失败原因。
SeqNo	SP用于标识唯一一次认证请求的号码。
RandomSessionKey	用户登录成功后的临时会话标识。
AreaID	用户的归属地ID 编码如下： 0001：北京0023：湖南 0002：上海0024：福建 0003：天津0025：甘肃 0004：重庆0026：四川 0005：黑龙江0027：广西 0006：吉林0028：贵州 0007：辽宁0029：海南 0008：内蒙古0030：西藏 0009：河北0031：新疆 0010：河南0032：香港 0011：广东0033：澳门 0012：湖北0034：台湾 0013：山东 0014：浙江 0015：安徽 0016：江苏 0017：江西 0018：云南 0019：宁夏 0020：青海 0021：山西 0022：陕西

4、查询用户信息接口

接口名称	QueryUserInfo
接口描述	SSO平台向SP系统开放的查询已登录用户信息接口。为提高性能，建议SP使用查询用户信息接口时使用"Keep-Alive"。
接口协议	HTTP协议
接口方向	请求：SPà中央SSO平台响应：中央SSO平台àSP

查询用户信息接口请求的参数描述：

字段名称	字段说明
ICPCode	SP的企业代码，长度为6位，格式是9XYnnn,XY表示SP接入地的短信网关编号，nnn表示序列号。
ICPPassword	SP的密码，该字段要求使用统一的DES算法加密，并用SP的密码作为加密算法的密钥。
SeqNo	SP用于标识唯一一次认证请求的号码
RandomSessionKey	用户的临时会话标识

查询用户信息接口响应的参数描述：

响应中的BackURL上以[BackURL]?[参数名称1]=[参数值1]&[参数名称2]=[参数值2]的形式返回以下输出参数：

字段名称	字段说明
ResultID	SSO平台处理的结果，为0表示成功，其它表示失败。失败时将在ResultString字段将表示错误信息。失败时不返回PseudoCode和MSISDN字段。
ResultString	ResultIDid为0时，内容为”OK”。失败时将在本字段表示具体失败原因。
SeqNo	SP用于标识唯一一次认证请求的号码。
PseudoCode	用户伪码要求可以配置成：当响应包中有MSISDN字段时，填或不填该字段。即当不填MSISDN时，此字段为必填项；当响应包中有MSISDN字段时，则根据配置决定响应包中是否需要该字段。
MSISDN	用户手机号码（要求能维护一个icp列表，对列表中有的icp才填该字段，否则，响应包中不包含该字段）
AreaID	用户的归属地ID。定义与用户登录接口响应信息中定义的AreaID一样。
OtherInfoNumber	返回包中Other_Info的个数。 Other_Info是为了今后能够灵活扩展接口中传递的信息而定义的数据类型。本字段表明在该XML包中存在的Otner_Info的数目。
Other_Info[]	表示其他信息数据。 OtherInfoNumber等于多少，在该XML包中就有多少个Other_Info。在Other_Info的结构中，包含两个字段： InfoCode：表示信息代码 InfoValue：表示具体的信息值

5、用户订购业务与点播下载业务的处理流程

• SP接入MISC平台的实施说明

由于MISC平台的建设有一个由点到面，逐步铺开的过程，因此在实施订购接口时需要考虑对于没有接入MISC的服务如何与已接入MISC的服务区别对待的问题。

根据服务接入MISC的情况不同，会有以下几种情况：

1）服务在MISC单点接入的情况

2）服务不在MISC接入的情况

3）服务多点接入时，主接入点和分接入点都接入MISC的情况

4）服务多点接入时，主接入点接入MISC，而分接入点没有接入MISC的情况

• 需要特别说明的是，在实现订购功能时，SP需要根据服务接入地选择SSO平台，即订购请求链接需要指向服务接入地的SSO平台，对于多点接入业务，则指向服务主接入地的SSO平台；如果服务接入地没有建设SSO平台，则指向中央SSO平台。

6、SSO订购、点播接口定义

业务订购与下载接口

接口名称	业务订购与下载
接口描述	SSO平台向SP系统开放的用户业务订购和下载功能接口，本接口根据参数的不同，有两种不同的用途： 1) 完成业务订购、取消订购、激活订购和暂停订购等操作 2) 完成下载类业务的临时订购，并返回临时订购关系ID
接口协议	HTTP协议
接口方向	请求：SPà中央SSO平台响应：中央SSO平台àSP

业务订购与下载接口请求的参数描述：

字段名称	字段说明
ICPCode	SP的企业代码，长度最长为6位，格式是9XYnnn,XY表示SP接入地的短信网关编号，nnn表示序列号。
ICPServID	SP提供的短信业务的业务代码，变长（小于等于10位）的字符串。如果是批量订购，则该字段可能包括多个业务代码，多个业务代码之间用逗号（“,”）分隔。
SeqNo	SP用于标识唯一一次认证请求的号码。
ItemID	用于标识SP的即时下发类业务（铃声、图片等）唯一性的标识，长度及格式由SP自行约定，应只包含数字和ASCII字符。本字段只对下载业务有效，即只有当ActionID为10时才需要，ActionID为其他值时参数中不应包含本字段。例如，如果用户订购的是天气预报、新闻等包月服务，则不需要带此参数。
MSISDN	用户在SP网站上输入的手机号码（此参数为可选参数）
ActionID	标识用户的操作，如订购、取消订购、暂停、激活等，长度为2位的整数，取值区间： 1：订购服务；2：取消服务； 3：激活服务；4：暂停服务； 10：点播下载服务。
BackURL	处理完成后要求SSO平台重定向用户到的目的URL。
DeliverURL	SP的服务下发请求接口地址。该参数为可选参数，当订购完成后SP需要向用户下发服务时填写该参数（ActionID＝10时）。当订购完成后还需要向用户下发服务时，SSO平台将向该参数定义的地址发起一个HTTPGET请求，以通知SP向用户下发指定的服务，请求中携带的参数格式参见服务下发请求接口。

• SSO订购、点播接口定义

• 业务订购与下载接口响应的参数描述：

响应中的BackURL以[BackURL]?[参数名称1]=[参数值1]&[参数名称2]=[参数值2]的形式返回以下输出参数：

字段名称	字段说明
ActionID	标识用户的操作，如订购、取消订购、暂停、激活等，长度为2位的整数，取值区间：参见上表。
ResultID	SSO平台处理的结果，0表示成功，其它表示失败。失败时不返回ResultString字段。如果是批量订购，则该字段中包含多个返回码，多个返回码之间用逗号（“,”）分隔，分别对应批量订购中的每个服务。例如，如果批量订购3个业务，第1和第2个服务订购成功，第3个服务由于服务代码错误订购失败，则该字段的值为0,0,4110。
ResultString	ResultID为0时，内容为”OK” 失败时将在本字段表示具体失败原因。如果是批量订购且部分成功时，则该字段为“部分成功”
SeqNo	SP用于标识唯一一次认证请求的号码。
RandomSessionKey	用户登录成功后的临时会话标识。
ICPServID	SP提供的业务代码，变长（小于10位）的字符串。
TempAuthNo	由SSO平台生成的本次订购操作的临时订购关系ID，只对下载业务有效，即只有当ActionID为10或 5时才返回该字段，ActionID为其他值时不返回该字段。另外，只有在请求处理成功，即result为0 时才返回该字段。
ItemID	用于标识SP的即时下发类业务（铃声、图片等）唯一性的标识，长度及格式由SP自行约定，建议只包含数字和ASC字符。其值将与请求中的ItemID的值相同。本字段只对下载业务有效，即只有当ActionID为10时才返回本字段，ActionID为其他值时不返回本字段。
FeePseudoCode	计费用户伪码；当响应包中没有FeeMSISDN时，此字段为必填项；当响应包中有FeeMSISDN字段时，则该字段为可选字段。
FeeMSISDN	计费用户的手机号码；要求能维护一个icp列表，对列表中有的icp才填该字段，否则，响应包中不包含该字段
DestPseudoCode	被赠送者的用户伪码；当用户输入了多个被赠送用户手机号码时，多个伪码之间用逗号（“,”）分隔。该字段仅当请求中的ActionID为5时有效，ActionID为其他值时不返回本字段；当响应包中没有DestMSISDN时，此字段为必填项；当响应包中有DestMSISDN字段时，则该字段为可选字段。
DestMSISDN	被赠送用户的手机号码；当用户输入了多个被赠送用户手机号码时，多个号码之间用逗号（“,”）分隔。该字段仅当请求中的ActionID为10时有效，ActionID为其他值时不返回本字段；要求能维护一个icp列表，对列表中有的icp才填该字段，否则，响应包中不包含该字段

7、服务下发请求接口

接口名称	服务下发请求接口
接口描述	SP系统向SSO平台开放的服务下发请求接口用于完成向用户下发服务的功能。该接口主要用于处理SSO平台在用户完成服务订购后需要向用户下发服务时的情况。
接口协议	HTTP协议，使用GET请求
接口方向	请求：SSO平台àSP 响应：SPàSSO平台

服务下发请求接口的参数描述：

ICPCode	SP的企业代码，长度最长为6位，格式是9XYnnn,XY表示SP接入地的短信网关编号，nnn表示序列号。
ICPServID	SP提供的短信业务的业务代码，变长（小于等于10位）的字符串。
SeqNo	SP用于标识唯一一次认证请求的号码，该号码与SP在服务订购请求中的传入的SeqNo相同；
ItemID	用于标识SP的即时下发类业务（铃声、图片等）唯一性的标识。该字段为可选参数；该字段的值与SP在服务订购请求中的传入的ItemID相同。
FeePseudoCode	计费用户伪码；当响应包中没有FeeMSISDN时，此字段为必填项；当响应包中有FeeMSISDN字段时，则该字段为可选字段。
FeeMSISDN	计费用户的手机号码；要求能维护一个icp列表，对列表中有的icp才填该字段，否则，响应包中不包含该字段
DestPseudoCode	接收服务的用户的伪码；当需要向多个用户下发服务时，多个伪码之间用逗号（“,”）分隔。当请求中没有DestMSISDN时，此字段为必填项；当请求中有DestMSISDN字段时，则该字段为可选字段。
DestMSISDN	接收服务的用户的手机号码；当需要向多个用户下发服务时，多个号码之间用逗号（“,”）分隔。要求能维护一个icp列表，对列表中有的icp才填该字段，否则，响应包中不包含该字段
LinkID	临时订购关系的匹配码，用来鉴权一次点播请求等事务性的业务。

第二章、业务改造分册

MISC系统结构和作用

SP接入MISC流程

SP升级前后特性对比

业务梳理及业务代码改造

点播、订购指令MO匹配

订购、取消及包月收取

业务组合模式说明

特殊业务流程举例

一、业务改造

1、业务改造重要性说明

• 业务改造是否合理决定了SP的业务能否顺利接入MISC，所以请各SP在培训完后尽快派专人进行分析和梳理业务的工作。业务改造分为以下几个步骤：

1）业务类型划分

2）业务代码整理

3）点播、定制指令设置

4）资费信息设置

5）反向订购业务申请

2、SP升级前后特性对比

项目说明	升级前状态	升级后状态
• 订购关系保存	所有订购关系由SP自行掌握	订购关系同时保存在MISC系统和SP系统中，但是以MISC系统中的订购关系为准
• 订购、取消通知下发	SP自行组包生成订购、取消通知消息下发给用户	MISC平台根据SP申报的短信提醒下发给用户
• 0000、00000统一取消指令	SP收到0000时组包产生取消菜单下发给用户，收到00000自行取消用户订购关系	MISC平台拦截0000指令并自行组包产生菜单下发，拦截00000指令自动取消用户订购的所有业务
• 包月话单发起扣费	由SP自行发起SMC包月扣费请求	由MISC根据有效用户订购关系代SP发起SMC包月扣费请求
• 订购、点播鉴权	不进行订购、点播鉴权，所有消息全部由网关透传给SP	所有的MO/MT消息都需要通过MISC的鉴权，实现有效拦截
• 订购关系同步	订购关系都保存在SP方，不存在订购关系同步	订购关系保存在MISC系统，所有的订购请求都由MISC通过Provision接口与SP同步
• 网站订购、点播处理	SP的网站点播和定制都由SP自身来控制，网关负责消息转发	SP的所有网站点播和定制业务都需要通过调用SSO接口来实现

业务梳理及改造过程

项目说明	升级前状态	升级后状态
• 业务类型梳理	CMPP2.0时期，业务类型分为三种：IOD、PUSH、STK类	升级后，业务类型按照最新的数据部管理规范，分为5种类型：点播类、定制类、STK点播类、STK定制类、帮助信息类
• 业务代码整理	IOD类型业务代码统一设置为：XXXX，PUSH类型业务代码统一设置为：－YYYY，STK类型业务代码设置为：+ZZZZ	点播类业务统一设置为：XXXX，定制类业务统一设置为：－YYYY，STK点播的业务设为：＋ZZZZ，帮助信息类代码设为：HHHH
• MO正向指令设置	所有的用户使用指令，包括手机点播和手机定制的指令都是由SP自行设置，网关不做任何处理	所有的手机点播和手机定制指令都必须在MISC平台中有数据，每次MO过程MISC都需要根据指令内容和长号码来判断业务
• 特殊业务流程整理	SP根据自身业务推广需要，可以灵活设置不同的业务流程，网关不做限制	由于目前MISC不支持二次批价，所以很多SP的特殊业务，例如促销、打折等业务都需要首先按照MISC的管理规范来设置

3、业务类型分类说明

• 业务分类方法

– 从计费方式上分为：按条计费，包月计费，免费使用

– 从使用方式上分为：点播类，定制类

– 从点播，定制来源上分为：手机，网站，STK卡

• 业务分类原则

– 定制类业务允许按条、包月和免费三种资费类型，用户必须订购业务SP才可以下发信息

– 点播类业务不允许包月计费，用户必须点播后SP才可以下发信息

• 具体业务分类

– 手机定制类，网站定制类，STK卡定制类

– 手机点播类，网站点播类，STK卡点播类

– 帮助信息类

• 定制类[手机]

– 用户必须订购，订购方式是使用手机MO上行信息，允许包月、按条、免费使用三种计费方式

– 业务申请时需要提交订购指令和退订指令

– 业务代码前以“-”号开头

• 定制类[网站]

– 用户必须订购，订购方式是通过SP网站或者是移动公司门户网站定制，允许包月、按条、免费使用三种计费方式

– 因为是在网站上进行交互方式订购，所以业务申请时不需要提交订购指令和退订指令

– 业务代码前以“-”号开头

• STK定制类

– 用户必须订购，订购方式是通过固化在STK卡中的相关菜单，允许包月、按条、免费使用三种计费方式

– 业务申请时需要提交订购指令和退订指令，此指令已固化在STK卡中

– 业务代码前以“+”号开头

• 点播类[手机]

– 用户必须点播SP才可下发信息，点播方式是使用手机发送上行MO信息，允许按条、免费使用两种计费方式，不允许包月

– 业务申请时需要提交点播指令

– 业务代码前无任何符号

• 点播类[网站]

– 用户必须点播SP才可下发信息，点播方式是通过SP网站或是移动公司门户网站点播，允许按条、免费使用两种计费方式，不允许包月

– 因为点播操作是在网站上交互进行，所以业务申请时不需要提交点播指令

– 业务代码前无任何符号

• STK点播类

– 用户必须点播SP才可下发信息，点播方式是通过固化在STK卡中的相关菜单，允许按条、免费使用两种计费方式，不允许包月

– 业务申请时需要提交点播指令，此指令已固化在STK卡中

– 业务代码前以“+”号开头

• 帮助信息类

– 此类业务必须免费提供，供SP向用户下发业务使用帮助信息，此类业务需要严格控制，建议要求每个SP只能申请一个

– 业务申请时不需要提交点播指令，也不需要提交订购指令和退订指令

– 业务代码前无任何符号

4、业务类型分类说明

业务类型	点播指令	订购指令	退订指令	订购关系	允许计费模式	业务代码格式要求	原有业务分类
点播类[手机]	需要				按条，免费		IOD
定制类[手机]		需要	需要	需要	按条，包月，免费	“－”前缀	IOD
点播类[网站]					按条，免费		PUSH
定制类[网站]				需要	按条，包月，免费	“－”前缀	PUSH
STK点播类	需要				按条，免费	“＋”前缀	STK
STK定制类		需要	需要	需要	按条，包月，免费	“＋”前缀	STK
帮助信息类					免费		PUSH

• 点播类业务

业务代码前不需要带“＋”，“－”号

• 定制类业务

业务代码前需要带“－”号

• STK类业务

业务代码前需要带“＋”号

• 帮助信息类业务

业务代码前不需要带“＋”，“－”号

二、MO指令规划建议

1、MO指令规划

• 接入MISC1.6以后，所有的MO消息都会通过MISC进行鉴权，由MISC系统来实现SP业务的MO正

向定制、正向取消和点播，而这些操作都必须在MISC系统中先申请设置好相应的定制指令、取消指令和点播指令。

• 所以SP在做接入前需要针对公司相关业务进行不同指令的规划和设计，MISC系统目前支持一个业

务多种MO指令的匹配方式以及多条指令的匹配方式，所以可以做到SP的旧指令最少改动。

• 不过不排除有些SP有一些非常特殊的业务指令需要重新设计和申请，因此指令规划这项工作也是必须的。

• SP在规划指令的时候要注意以下几点：

1、点播、定制、取消指令不能使用保留字进行精确匹配：

例如“cmcctest”是保留字，如果选择精确匹配，则指令内容不能是“cmcctest”，但指令内容可以

为cmcctest1、cmcctest*、cmcc或cmc、000或000000等，因为用户上行cmcctest或0000时，不会

匹配到这些业务。不能采用和模糊匹配同样的校验原则，因为某些业务的精确匹配指令很有可能是

0或者00或者是C等等。

2、如果选择模糊匹配，则指令内容不能是保留字的任一包含第一位字符的子串，且不能是以保

留字开头的字符串。例如保留字“cmcctest”，如果选择模糊匹配，则指令内容不能是“c”、“cm”、

“cmc”、“cmcc”、“cmcct”、“cmccte”、“cmcctes”、“cmcctest”，且也不能是“cmcctestA”、

“cmcctest*”等等。

3、保留字不区分大小写，目前保留字有：“cmcctest”、”chinamobile”、”0000”、”00000”。

4、定制指令内容不允许为空。

2、MO指令的匹配过程

• MO指令匹配功能使SP可以针对不同的业务设置不同的定制、取消、点播等指令，同时还可以针对特服号实现长号码功能。另外，MISC支持灵活多变的匹配模式，包括长号码和指令内容的模糊和精确匹配、空指令匹配等

• 指令的种类：

MO指令分为4种：订购指令、取消指令、点播指令和普通MO，并可分别指定对发送号码和指令内容是否需要做精确匹配。

• 精确匹配说明：

是指只有当所匹配内容和所设置的指令完全相同（包括长度也一样）时，系统才能够匹配成功

• 最大匹配说明：

相当于模糊匹配。对于长号码或者指令，匹配位数相同的最多的字符串，如有两个模糊匹配的指令‘8001aa’、‘80011aa’，当用户发送‘800111aa’的时候，会匹配到第二条指令，而不是第一条

3、MO匹配流程

用户发起MO指令到SP长号码

指令匹配失败

MISC进行长号码匹配，成功后进行指令内容匹配

MISC进行指令内容匹配，成功后按照不同的流程处理

如果匹配的是订购指令，则走用户订购流程

如果匹配的是取消指令，则走用户取消流程

如果匹配的是点播指令，则走用户点播流程

如果匹配的是普通MO指令，则走普通MO流程

4、指令匹配流程说明

• 用户的MO短信由两部分构成：发送号码和发送的内容，再加上业

务申请时设置的匹配模式，这三样共同构成了匹配时的依据。

• 当一条MO到MISC进行鉴权时，MISC先对发送号码（长号码）进行匹配，按照最大匹配+精确匹配的原则进行，先精确匹配后模糊匹配。如果有匹配成功的，则取出对应业务代码和指令类型。

• 在上一步匹配出来的列表中，再对指令内容进行匹配，也是按照最

大匹配+精确匹配的原则进行，先精确匹配后模糊匹配。如果有能匹配上的结果，则取出对应的业务代码和指令类型；如果没有能对应上的匹配结果，则取列表中的最后一条的ServiceID作为匹配出来的ServiceID，同时通知短信网关将此条短信当作普通MO向SP转发。

• 对于匹配成功的指令，MISC根据匹配出的指令的模式不同，会有

不同的处理方式。

5、MO正向订购流程举例

三、指令流程说明

1、订购指令匹配处理流程

• 对于订购指令，MISC将检查该用户是否已订购该服务，如果没有订购，则MISC将会完成订购，同时会将用户MO中的内容通过用户订购关系数据同步接口（Provision接口）传送给SP，在Provision接口中的FeatureStr字段（base64加密）中将会有用户MO的长号码和指令内容，长号码和指令内容之间以空格符分隔。同时MISC会通知短信网关这是一条订购指令，短信网关将不向SP转发该MO。

• 如果该用户已订购该服务，MISC会将该MO当作普通MO向短信网关返回鉴权成功的结果，通知短信网关将此条短信当作普通MO向SP转发。

2、取消指令匹配处理流程

• 对于取消指令，则MISC将检查该用户是否已订购该服务。如果已经订购，则MISC会将订购关系取消掉，同时将用户MO中的内容通过用户订购关系数据同步接口（Provision接口）传送给SP，在Provision接口中的FeatureStr字段（base64加密）中将会有用户MO的长号码和指令内容，长号码和指令内容之间以空格符分隔。

• 如果该用户未订购该服务，则MISC会向短信网关返回鉴权失败，短信网关将不会向SP转发该MO。

3、点播指令匹配处理流程

对于点播指令，则MISC会生成临时订购关系（LinkID），同时向短信网关返回鉴权成功，并将LinkID返回给短信网关，由短信网关将该MO作为点播MO向SP转发。

4、普通MO匹配处理流程

• 对于普通MO短信，MISC向短信网关返回鉴权成功的响应，同时通知短信网关将此条短信当作普通MO向SP转发。

•

5、MO匹配实例

seqAccessNOFeatureStrANCheckFlagFSCheckFlag

18888xw10

2888801xw00

3888801xw101

4888801xw11

58888(null)00

【注】AccessNO表示MO的发送号码

FeatureStr表示指令内容

ANCheckFlag表示对AccessNO是否使用精确匹配（1代表精确匹配）

FSCheckFlag表示对指令内容是否使用精确匹配（0代表模糊匹配）

针对上面的设置：

用户发送xw1到8888011我们匹配第3条记录

用户发送xw01到888801我们将匹配到第2条记录(先最长匹配接入号)

用户发送01xw到888802我们匹配到第5条记录（不会匹配到第4条记录，因为第4条记录的AccessNO是精确匹配）

用户发送01xw到8888我们匹配到第4条记录

用户发送xw01到8888我们匹配第1条记录

用户发送A到8888我们匹配第5条记录

四、业务规划

• 订购业务种类规划

• 定制、取消点播指令设置

• 反向订购业务申请

• 统一反向取消接口开放

• 包月话单收取

•

1、订购业务种类规划

• 接入MISC1.6平台以后，SP的所有订购关系都保存在MISC平台中，并且以MISC平台中的为准，所以所有用户的订购必须先通过MISC平台来实现，因此SP需要针对DSMP平台管理规范要求来规划各自定制业务的种类。

• 比如，哪些业务需要通过MO正向来定制，哪些业务需要通过网站定制等，另外还有就是需要规划哪些按次的业务需要定制，注意，包月的业务是必须设置为定制业务，否则不能产生包月扣费

•

2、定制、取消点播指令设置

• 规划好了哪些业务需要定制以后，接下来就是要规划这些业务的定制和取消指令了。SP针对每一个业务都可以设置多个定制、取消指令，但是指令必须不相同，建议不超过5个。

3、反向订购业务申请

• 考虑到有部分用户有一些特殊业务或者合作类业务，不能通过正向MO指令定制的方式实现的，所以需要提供反向定制方式实现。但是申请反向定制业务必须满足以下几个条件：

– 用户通过自动语音平台订购的业务，可以使用反向订购；此处语音平台不包括SP的客户服务电话，人工台等语音途径；

– 用户通过SP专有客户端进行订购的业务，该客户端不支持HTTP协议，不能通过程序改造的方式实现网站订购；

– 用户通过STK卡固化指令订购的业务，该固化指令不符合现网MISC的订购指令要求格式，不能由MISC解析。同时，该STK卡用户已普及而且不能修改。可以使用反向订购；

– 用户通过与SP或其合法代理机构签定具法律效力的协议文本或合同文本订购的业务，可使用反向订购；

– 对于同一个业务在不同时期资费优惠的情况，原则上不允许使用反向订购；

– 属于集团客户业务，即使用业务的用户属于固定用户群，无需主动订购或主动取消业务，订购

或取消业务按集团客户内部管理规定处理。如果此类业务确实需要纳入MISC的管理范围，可以使用反向订购

• 申请反向订购业务时，SP需单独填写反向订购业务申请表，并随表递交附件：《SP名称－反向订购业务申请》，对每一项业务，申请内容须包括：

– 业务订购过程

– 业务取消过程

– 申请反向订购的原因

– 订购行为记录格式与查询方法

– 业务开通时间、订购用户数、所占SP业务总量比例

4、统一反向取消接口开放

考虑到用户投诉时一般都会直接投诉到SP那里，MISC1.6平台按照DSMP规范修订的要求，开放了统一反向取消接口功能，所有SP都可以通过该接口实现对定制业务的取消操作，方便了SP处理用户取消业务的投诉，但是前提是SP必须实现正向订购关系同步接口（Provision）的应答处理。

5、包月话单收取

• 按照旧的业务流程，包月话单是由SP自己控制，并且直接下发给网关实现包月扣费。但是接入MISC1.6平台以后，所有的包月扣费请求都是由MISC平台直接向网关发起，实现包月扣费，而不再由SP自行发起包月扣费。

• 对于订购包月业务，用户订购后有72小时的优惠试用期，订购后72小时内取消该业务不收费，即在订购关系确认72小时后，方能发送SMC话单。订购时间以MISC中产生的订购时间为准。用户订购后，MISC将记录订购时间，72小时后，用户未取消业务，MISC将产生SMC包月话单。

• 对于订购包月业务，每月20日(包括20日)后订购不收取当月包月费。用户订购后，MISC记录订购时间并依据自身系统时间判断是否为20日。如果在20日之前，MISC将执行72小时的优惠条件；如果在20日之后(包括20日)，MISC只保存订购关系，当月不产生话单，如果用户在该帐期内未取消该订购关系，下一个帐期MISC将开始计费，生成SMC包月话单。

• 每月20日前三天发生的72小时优惠，将不享受20日后订购免费的优惠。MISC将以第一次在MISC中产生的订购时间为准，72小时后确认订购关系是否存在来生成SMC包月话单。

• 用户当月第二次订购同一包月业务时，立即收费，即发送SMC包月话单。MISC保存用户订购、取消的历史记录，发现用户当月订购同一业务时，将立即生成SMC包月话单；如果两次订购都发生在当月20日(包括20日)后，则不收费。

五、业务组合模式说明

• 关联业务组合

• 不同等级业务组合

• 套餐式业务组合

• 普通业务组合

1、关联业务组合

• 比如网上宠物业务，每月收费5元，另外在这个业务基础上，还可以增加短信通知功能，将宠物每日的信息随时通知用户，每月加收3元，也就是说，宠物业务为主业务，必须订购了主业务之后，才能订购短信通知业务。这是主从关系。

• 针对这种组合方式，可以很容易形成各种业务模式，将以前一些不好控制信息费的业务拆分成两个关联业务来处理，比如股票预警业务，可以有一个主业务，设置为包月的，一个主业务中，最多可设置4支股票的预警，但要限制最多的发送条数，另外设置一个从属业务，按条收费，不限制条数，如果本月用户的预警信息不超过限制值，就会用包月服务的代码下发，如果超过了50条，就用按条的业务下发。

2、不同等级业务组合

• 比如邮箱业务，有10M、20M、50M之分，收费不同，但同一个用户，同一时间内，只能订购所有这些业务之间的一个，而不能同时订购10M、20M两个，并且用户从业务组内的某一项业务换成别一项业务时，是升级，而不是取消某一项业务，再订购另一项业务，这是为了保证用户的业务相关信息的延续性，这是互斥关系。

• MISC在处理这种业务组合时，当有用户订购组合内的某一个业务，MISC会检查用户是否订购了该组合内的其他业务，如果有订购，就会取消用户订购的本组内的其他业务，这样，用户不需要手工去取消原来订购的业务，直接选择订购组合内的新业务就可以完成业务转换，这样带来的直接好处就是用户使用方便，不会因为业务的转换带来多重收费。

• SP在处理这种业务时，也一样需要判断用户是否有订购过本组内的其他业务，如果有订购，SP要求进行业务升级，而不是取消原业务再订新业务，这样主要是保持业务信息的连续性，不至于因为业务升级而丢失原来的信息。比如邮箱从10M升到50M，原10M邮箱里的信就不会丢失了。

3、套餐式业务组合

• 这是为了业务宣传的需要而将一些不相关联的业务放在一起，比如某SP对外宣传了一项“新年快餐”业务，这里面包含有5项业务，虽然这些业务可能并不相关，但为了业务推广的需要以及用户订购与查询的方便，也为了业务统计的需要，而将这些业务组合在一起。这些业务之间没有关联，订购时也是分别订购，而不能订购一个业务组。

• 另外一种提法，套餐业务组合其实就是SP的个性化业务分类。因为总的业务分类是由运营商规定的，不会因为某个SP而变化，SP如果想要自己的业务分类怎么办？套餐业务组合也可以这样来用，SP可以自己设置一个业务分类，比如“奥运快迅”，然后把与此有关的所有业务放在这个分类里，这样在PORTAL的展示上，就会把这些业务放在一起，让用户很方便的找到。由此就可以延伸出“财经频道”、“体育频道”等一系列这样的套餐。

4、普通业务组合

• 目前定义的有手机点播类、网站点播类、手机定制类、网站定制类、STK等业务模式，一个业务，SP可以用多种模式向用户提供服务，也可以在同一种模式下，以不同的资费方式向用户提供。比如一个股票价格预警业务，SP可以同时提供按条计费、包月计费方式，因为预警的信息条数不可预知，所以用户可以选择按条计费，另外也可以包月，SP只发送有限条的信息，超过后就不再发送；另外比如一个新闻业务，SP可以提供自动PUSH方式、手机点播方式等，这些使用方式的计费各不相同。为了用户订购的方便，也为了业务统计的方便，将这些业务放在同一个组内。

• 采用这种组合，可以将一个业务分成多个业务，同样的内容同时满足不同用户的要求，这对业务的推广和宣传无疑都是有很大的好处的。

5、特殊业务设计举例

• 包月定制类业务需要免费使用N个月

• VIP用户群免费使用业务

• 游戏、聊天类业务

• 手机股票信息点播、定制

6、包月定制类业务需要免费使用N个月

• 业务流程：

用户发送“M”到xxxx，SP判断如果是新用户则发送游戏介绍的免费短信给用户，并且给用户自动定制成为游戏用户的免费用户；如果是老用户则直接返回游戏菜单给用户，使用时通过直接回复来实现。如果用户在一定的时期内没有上行消息，那么该用户不收费，如果有上行消息，则试用期到后自动转为收费用户

• MISC建议方案：

SP新申请一个免费的定制业务，用户首次使用时发送M到xxxx先定制上这个免费的业务，等到过了试用期后由SP发一个二次确认的短信给用户，让用户回复MF到xxxx通过MO正向定制收费的业务，如果用户没有确认，则SP通过反向取消接口清除该用户定制的免费业务；如果用户发送确认消息确认订购，则MISC会定制该业务，并且把订购请求通过Provision接口同步给SP，SP收到该请求后把之前定制的免费业务代码取消掉即可

7、VIP用户群免费使用业务

• 业务流程：

针对不同的用户群，当定制某一项业务时，如果是普通用户定制，那么按照正常的收费标准来收费，如果是VIP用户则免费。

• MISC建议方案：

专门针对VIP用户设置一个单独的业务代码（免费），当用户成为VIP用户后，先通过反向取消接口把原来定制的收费业务取消掉，然后通过反向订购接口帮VIP用户来订购这个免费的业务，之后就使用这个免费的业务代码来给用户下发业务了

8、游戏、聊天类业务

• 业务流程：

用户发送MF定制游戏或者聊天类业务，使用时同时也是使用相同的指令来开始游戏或者开始聊天等

• MISC建议方案：

– 把MF设置成一个定制指令，当用户第一次发送MF到xxxx的时候，MISC判断该用户如果没有定制该项业务，则按照定制流程完成业务定制操作。

– 如果用户定制成功了，之后用相同的指令去使用业务时，MISC判断用户已经订购了该项业务，那么MISC会把这个MO当成一个普通点播消息通知网关发送给SP而不做拦截，SP收到后就可以按照业务流程给用户下发消息了

9、手机股票信息点播、定制

• 业务流程：

v 用户拨打1259098+股票号码或者发送短信1259098+股票号码到xxxx来定制股票业务，用户定制成

功后SP会定期给用户下发股票信息，业务区分都是通过短信内容来区分，比如12590981+股票号

码表示定制个股点评包月业务，发送1259098+股票号码表示定制个股管家按条业务。

v 另外用户可以通过拨打客服电话，通过SP的客服人员代用户定制各类业务。

v 同时，SP在某个特定的日期或月份开始促销，这样可能会对所有定制的业务进行免费使用N个月促

销活动，使用方法同上，只不过扣包月费由SP控制，如果是免费的用户则本月不扣包月费，但是

对于按次的业务不做处理。

• MISC建议方案：

针对不同的业务设置点播指令和定制指令，指令格式：“1259098＋股票代码”，由于股票代码的前

一位比较固定，所以我们可以针对个股点评的定制指令设成多个定制指令，比如“1259098＋0＋股

票代码后几位”，或者“1259098＋6＋股票代码后几位”，因为股票代码的前一位是固定的。

针对用户打电话到SP客服要求取消或代定制业务的方式，建议SP引导用户通过梦网

www.monternet.com或1860客服去定制或取消，也可以通过发送0000、00000来取消业务。

针对首次订购使用免费的业务或者哪些地区的新用户免费使用的业务，采用申请一个免费的订购业

务来做免费业务定制，过了免费期以后由SP发送一个需要确认的短信提醒给用户，用户回复一个

定制收费业务的定制指令到MISC做正向定制，如果用户在一定时间内没有确认，则SP在自己的资

料库里面把这个免费的业务取消掉

第三章、SPOA分册

系统概述

短信合作申请管理

短信业务管理

公共信息

私有信息

投诉处理

一、系统概述

移动梦网运营管理系统介绍

SP自服务系统介绍

1、移动梦网运营管理系统介绍

移动梦网运营管理系统是移动梦网MISC平台的一个子系统

该系统以Web方式提供SP合作申请管理、梦网SP和梦网业务管理、用户投诉和SP投诉管理、以及梦网业务数据统计等功能，以满足移动梦网运营中所涉及的业务管理需求。

该系统包括移动梦网业务管理子系统（Admin）、移动梦网SP自服务管理子系统（SPOA）和移动梦网1860客服管理子系统三个子系统（1860）。

分为全国运营中心和省运营中心两大部分:

中央（Admin、SP）

省站（Admin、SP、1860）

. . . . . .

2、SP自服务系统介绍

SP自服务管理系统是业务运营管理系统的一个子系统

该系统使用对象为SP，主要为SP提供合作申请、业务管理、公共信息与私有信息的管理、处理用户投诉以及向接入省移动公司或集团公司投诉等功能。

该系统分中央站点和省站：

中央站点部署在移动集团公司，提供全网短信、WAP和PDA业务相关的合作申请、业务管理、信息管理以及投诉处理等功能；

省站部署在各省移动公司，提供本地短信业务、本地短信业务升级成全网短信业务和本地WAP业务相关合作申请、业务管理、信息管理以及投诉处理等功能,以及全网服务的本地接入短信合作申请、业务管理、信息管理、投诉处理功能。

申请与中国移动公司合作开展移动梦网业务，可参考《移动梦网SP合作管理办法》SP

二、短信合作申请管理

注册登录账号

本地合作申请流程

SP合作申请资料填写说明

本地升级全网合作申请流程

短信全网合作申请流程

全网服务的本地接入合作申请

1、注册登录账号

• 通过web浏览器访问接入省的SP自服务系统注册账号

2、本地新SP合作申请－流程图

SP申请非全网服务本地合作

SP向省公司提交合作申请资料和业务申请资料

省公司审批合作申请资料

省公司审批网络测试

省公司给SP分配企业代码、服务代码、短信网关等

省公司审批业务申请资料

省公司审批业务验证

省公司审批计费测试

成为非全网服务本地短信SP

合作申请注意事项

1）SP申请短信非全网服务的本地合作，需登录到SP自服务管理系统省站站点，填写本地合作申请资料和至少一项业务申请资料并提交。

本地合作申请资料填写说明，请参考SP合作申请资料填写说明。

本地业务申请资料填写说明，请参考短信业务申请资料填写说明。

2）SP要详细、准确地填写合作申请资料和业务申请资料，否则如果省移动公司对SP提交的申请资料审批不通过，SP有可能三个月内不得重新申请

3、SP合作申请资料填写说明

属性名称	属性说明
SP公司中文名	中文汉字、英文字母和.及,的组合。不超过100个字节
SP公司英文名	英文字母、中划线和.及,的组合。不超过300个字节
SP简称	不超过50个字节，允许中文与英文字母及.,的组合
公司地址	中文汉字、英文字母和.及,的组合。不超过100个字节
公司负责人	中文汉字。不超过40个字节
总裁联系人	中文汉字。不超过40个字节
开户银行	中文汉字、英文字母和.及,的组合。不超过100个字节
银行帐号	不超过30位的0至9数字与–及*的组合
结算方式	分为三种：按月以账单结算、分批付款、其它谈判确定方式
客服WEB地址	应以http://或开头 https://
接入方式	分为INTERNET与专线两种
主机位置	主机存放物理地址，例如“深圳数据局托管机房”。不超过30个中文汉字
短信系统登录MISC的口令	SP在MISC系统鉴权的口令，在系统中可修改此口令，请参见私有信息短信系统密码修改
服务代码	纯数字组成。全网业务服务代码长度统一为4位，即“1000”－“9999”；本地业务服务代码长度统一为5位，即 “01000”－“09999”。同省的各SP的服务代码不能重复。
服务接入地	SP提供业务的接入地。由系统自动生成，SP不可修改。

4、本地升级为全网SP申请流程

梦网本地短信SP申请全网合作

SP向省公司提交升级全网合作申请和业务申请资料

集团审批业务验证

集团审批计费测试

SP成为全网短信SP，其申请业务成为全网业务，并正式商用

集团审批业务申请资料

省公司审批合作申请资料

集团审批合作申请资料

集团审批网络测试

省公司审批业务申请资料

接入省公司与SP签订补充合作协议

5、全网SP本地接入合作申请

SP申请全网服务本地接入合作

SP向省公司提交合作申请资料和业务申请资料

省公司审批合作申请资料

省公司审批网络测试

省公司给SP分配企业代码、选择短信网关等

成为全网服务的本地接入短信SP

6、变更合作申请资料

根据可变更的内容，变更短信合作申请资料包括两种情况：

非全网服务的本地接入SP和全网SP

变更前提：SP状态为“成为梦网本地SP”或“成为正式梦网全网SP”。

可变更内容：SP的企业基本属性、业务第一联系人信息、客服信息、SP的网络基本属性和网络联系人信息；但服务代码和服务接入地不可变更。

全网服务的本地接入SP

变更前提：SP状态为“成为本地接入SP”。

可变更内容：全网服务SP的本地接入点可以对自己的个性化内容进行变更，但不

可对以下内容进行变更：SP公司中文名、SP公司英文名、SP简称、

服务代码、服务接入地、业务处理地址。

二、短信业务管理

业务组合与业务类型说明

短信本地业务申请流程

短信本地业务升全网申请流程

短信全网业务申请流程

申请业务变更

1、短信本地业务申请流程

SP申请短信本地业务

SP向省公司提交本地业务申请资料

省公司审批业务申请资料

省公司审批业务验证

省公司审批计费测试

成为梦网短信本地业务，但需要到商用时间才能正式商用

2、短信业务申请资料填写说明

SP申请将本地短信业务升级为全网短信业务

SP对本地业务提出全网升级申请

省公司审批业务申请资料

省公司审批业务验证

省公司审批计费测试

梦网本地短信业务升级为全网短信业务，并正式商用

集团公司审批业务申请资料

3、短信全网业务申请流程

短信全网业务申请流程与短信本地业务申请流程基本相同，请参考短信本地业务申请流程。

不同之处：

申请短信本地业务需登录SP自服务管理系统省站，由省移动公司管理员审批；

申请短信全网业务需登录SP自服务管理系统中央站点，由移动集团公司管理员审批。

4、申请短信业务变更

业务变更申请前提

只有状态为“本地商用”、“保留为本地业务”（梦网本地SP在申请全网合作过程中的本地商用业务）和“全网商用”的短信业务才可申请变更。

业务变更内容

业务变更包括对原有业务的业务名称、业务分类、业务描述、资费类型、资费、发送频率、业务处理地址、点播指令、定制指令、退订指令和LOGO图片等的更改，即除了业务代码和业务模式不能变更外，其余内容均可变更。

业务变更流程

本地短信业务变更需通过接入省公司的变更业务申请资料管理和变更业务计费验证审批。

本地短信业务升级成全网短信业务的业务变更需通过省公司初审变更业务申请资料、集团公司复审变更业务申请资料、集团公司计费验证审批

直接申请成为全网短信业务的业务变更只需通过集团公司的变更业务申请资料管理和变更业务计费验证审批

三、通用信息

公共信息

信息公告

短信业务排名

会议通知

违规查询

1、公共信息介绍

信息公告

SP查看接入省公司和集团公司下发的信息公告，下载信息公告中的附件。

短信业务排名

登录到SP自服务管理系统省站，SP可以查询每月、年中或年末的梦网短信全网SP的业务排名情况和本省接入的梦网短信本地SP的业务排名情况。

会议通知

登录SP自服务管理系统，可查询、浏览中国移动集团下发给SP的会议通知，并可对会议通知作出“参加会议”或“不参加会议”的答复。

违规查询

各省移动公司和移动集团公司对违反相关条例的梦网SP记录违规事件，并公布给所有梦网SP。SP可通过本系统查看所有梦网SP的违规信息。

2、私有信息

登录用户管理

密码修改

短信系统密码修改

短信信息费查询

短信考核查询

投诉处理点修改

私有信息介绍

登录用户管理

SP管理员可对登录移动梦网SP自服务管理系统的SP用户进行管理，包括查询、添加、修改、删除SP登录用户信息功能，并可为登录用户分配操作权限。目前系统只向拥有投诉权限的SP客服坐席人员分配登录帐号。

密码修改

操作员可修改登录SP自服务管理系统的登录密码。

短信系统密码修改

操作员可修改短新系统接入MISC系统的密码。

短信信息费查询

登录到SP自服务管理系统省站，可以查询本公司历史某月的短信信息费费用明细。

短信考核查询

梦网短信SP登录到SP自服务管理系统，可以查询接入省移动公司或移动集团公司对本公司提供的梦网短信业务的月考核、年中考核和年末考核结果。

投诉处理点修改

多点接入的全网SP可以在本地接入点修改其本地接入点的用户投诉处理点，可以选择将本地接入点的用户投诉处理点设在本地或全网主接入点。

四、投诉处理

1、用户投诉

SP 系统

班长座席

普通座席

1860 客户服务中心

投诉单

处理结果

申请仲裁

仲裁结果

2、SP投诉

l SP投诉流程

SP提出投诉

提出网络问题

提出帐务问题

提出业务问题

提出其他问题

移动公司数据业务管理部门

数据部门分析原因，并转入相关处理流程

转入内部处理流程

反馈SP

投诉处理结果

l SP投诉

投诉功能是指SP的网络问题、帐务问题和业务问题等对省移动公司或移动集团进行投诉，同时为SP提供查看投诉处理结果、并对处理结果进行满意度反馈等功能。SP

梦网短信本地SP和梦网WAP本地SP登录到SP自服务管理系统省站，可对接入省公司提交投诉；梦网短信本地升级全网SP可对接入省公司或集团公司提交投诉。

梦网短信、WAP和PDA全网SP登录到SP自服务管理系统中央站点，可对集团公司提交投诉。

省移动公司数据部受理SP投诉后，可直接给出处理意见，也可以将投诉转发给本公司其它部门处理，最后由数据部将处理结果反馈给SP；集团公司数据部受理SP投诉后，可直接给出处理意见，也可以将投诉转发给本公司其它部门或省公司处理，最后由集团数据部将处理结果反馈给SP。

posted @ 2012-11-22 22:51 忍性而为阅读(1002) 评论(0) 编辑收藏举报

刷新页面返回顶部

生而为赢

MISC系统短信SP接入培训

公告