`
zhangziyueup
  • 浏览: 1160919 次
文章分类
社区版块
存档分类
最新评论

SP 短信开发-基础知识篇

 
阅读更多

很土的话题,但是最近帮朋友做这个东西,所以写点东西出来给初学者参考。
一、准备资料
SP开发资料网站上有很多,但是主要是以下几个文档:
1、MISC1.6 SP订购通知接口要求
2、SMPP协议
3、MISC系统短信SP接入培训(精简版).ppt
4、DSMP规范中的SSO平台接入规范详细说明 v1.5.1.pdf
5、可供SP查看的错误代码
6、DSMP规范中的SSO平台接入规范.pdf
7、互联网短信网关接口协议V3.0

二、短信业务分类

短信业务主要分2种,一种是点播业务,另外一种是定制业务
1、点播业务
其service_id前面没有-号,例如YLSH
说明:计费代码,和service_id就是一个东西
手机用户有发送过信息,sp才能下发信息,移动根据一个上行分配一个linkid,在一定的时间内sp可以给他下发信息,可以下发多条信息,但是每条的信息都是同一个linkid

,一个linkid可以带一个计费代码(这个是在移动申报的,凭这个代码扣费,1元或者2元或者N元)
例如手机13912345678 发了一个上行信息A,该指令是在移动申报过的,misc平台通过他,则分配一个linkid返回给sp,sp根据指令A来判断用户用了什么业务,然后给用户下

发信息,下发信息一定要带上lingkid和计费代码,否则不能下发,例如下发3条,每条信息的linkid和计费代码都是一样的(因为用户只有一个上行指令),所以其实虽然sp发了3

条,只能扣到一条的费用。带linkid和计费代码只是为了保证信息的成功下发的一个参数。所有的业务都是这样,点播,以及后面说的定制

2、定制业务:
其service_id前面有-号,例如-YLQTYX
手机用户发送过一次信息,经过misc鉴权,承认他愿意使用定制业务,则将他列为定制用户,之后,哪怕用户没有发过信息,sp也可以主动给他发信息,此时就没有分配

linkid了,只是service_id,也就是计费代码,每次下发信息都必须带上这个service_id才可以。

他还分两小类
1)、定制按条
sp可以给有定购关系的用户下发信息,用户每收到一条,就按照service_id标明的资费扣费,一个月,最多扣用户10元,超过10元的部分,还是需要带service_id下发,只是

移动不再扣费(该部分,sp不需要管)
2)、包月业务
sp可以给有定购关系的用户下发信息,所有的信息都要带service_id下发,扣费由移动发起,sp不管。

三、开发技术
只要满足第一点的协议和规范要求,用目前流行的开发语言和数据库等都可以做。
1、主要关键的是网络编程,和SOAP的编程
2、相关名词解释
MISC(Mobile Information Service Center移动信息服务中心)是一个完全符合中国移动数据业务管理平台技术规范(DSMP)的数据运营平台,它完成数据业务的业务管理和控制功

能,实现用户管理、业务管理和SP管理,对外提供开放的、标准统一的Web Service接口,并可以为各个业务网关、SP提供代计费。

SMPP接口协议最初由ETSI收录在 GSM03.39规范中,描述了短消息中心与短消息实体之间通信交互的协议关系及数据传输格式,本规范对SMPP接口协议的描述

主要面向简单的通信交互,制定规范的厂家将其协议版本号定为V3.30;后由SMPP开发者论坛将协议版本向前演进为V3.40,SMPP V3.40协议规范完全兼容G

SM 03.39协议标准。本规范中,所采用的短消息中心设备与短消息股票交易业务处理平台之间的接口采用GSM03.39 V3.30协议规范,如无特殊说明全部以此协

议规范为准。SMPP协议可以以TCP/IP或X.25作为底层通讯承载。

ISMGIntenet Short Message Gateway互联网短信网关

DSMPData Service Manage Platform数据业务管理平台

SMPPShort Message Peer to Peer短消息点对点协议

CMPPChina Mobile Peer to Peer中国移动点对点协议
CMPP协议主要提供以下两类业务操作:
(1)短信发送(Short Message Mobile Originate,SM MO)
详细的流程请参考《移动梦网短信业务信令流程规范V3.0.0》;
(2)短信接收(Short Message Mobile Terminated,SM MT)
详细的流程请参考《移动梦网短信业务信令流程规范V3.0.0》;


SMSCShort Message Service Center短消息中心

GNSGateway Name Server网关名称服务器(汇接网关)

SPService Provider业务提供者

ISMG_Id网关代码:0XYZ01~0XYZ99,其中XYZ为省会区号,位数不足时左补零,如北京编号为1的网关代码为001001,江西编号为1的网关代码为079101,依此类推

SP_IdSP的企业代码:网络中SP地址和身份的标识、地址翻译、计费、结算等均以企业代码为依据。企业代码以数字表示,共6位,从“9XY000”至“9XY999”,其中“

XY”为各移动公司代码

SP_CodeSP的服务代码:服务代码是在使用短信方式的上行类业务中,提供给用户使用的服务提供商代码。服务代码以数字表示,全国业务服务代码长度为4位,即“1000

”-“9999”;本地业务服务代码长度统一为5位,即“01000”-“09999”;信产部对新的SP的服务代码分配提出了新的要求,要求以“1061”-“1069”作为前缀,目前中国移

动进行了如下分配:
1062:用于省内SP服务代码
1066:用于全国SP服务代码
其它号段保留。

Service_IdSP的业务类型,数字、字母和符号的组合,由SP自定,如图片传情可定为TPCQ,股票查询可定义为11

DSMP 数据业务管理平台
SSO Single Sign On,单点登录
HTTP Hyper Text Transfer Protocol,超文本传输协议。
HTTPS Hyper Text Transfer Protocol over Secure Socket Layer,基于安全套接字层的超文本传输协议。
ICP Internet Content Provider,因特网内容提供商
WWW World Wide Web
XML eXtensible Markup Language,可扩展标记语言
Session 是指HTTP 访问过程中的一个完整会话过程

互联网短信网关(ISMG)是业务提供商(SP)与移动网内短信中心之间的中介实体,互联网短信网关一方面负责接收SP发送给移动用户的信息和提交给短信中心。另一方面,移动

用户点播SP业务的信息将由短信中心通过互联网短信网关发给SP。另外,为了减轻短信中心的信令负荷,互联网短信网关还应根据路由原则将SP提交的信息转发到相应的互联网短

信网关。互联网短信网关通过向汇接网关(GNS)查询的方式获得网关间的转发路由信息。
另外,ISMG还必须与数据业务管理平台DSMP进行连接,在业务流程中对用户、业务以及定购关系等进行鉴权并对业务进行批价。


3、接口命名规范
接口名称采用单词首字母大写,其他字母小写的方式。缩略语中的字母都大写;接口参数和消息内
容定义中,基本数据类型的字段命名规范采用单词首字母大写,单词间没有连接符的方式;对于缩写单
词,例如ID,URL、ICP、MSISDN 等,将统一采用大写。


SSO 平台实际上是用户归属地DSMP 的一部分功能。用户登录时都需要重定向到归属地DSMP 的用户自服务门户上,无论全网SP 还是本地SP,都是到用户归属地的SSO 平台做用户登

录,并且完成Session 的管理,用户订购的信息是存储在归属地DSMP 平台的,用户认证由归属地DSMP 完成。因此,SP 需要与接入地的SSO 平台连接,以便完成Session 的管理。

同时,在各个SSO 平台之间,也需要有一套机制管理和同步相互间需要的用户数据,以保证用户数据在任何SSO 平台上都可以得到。为实现这个要求,建议采用集中控制、各点按

需同步的方式实现,也就是在整个DSMP 部署架构中存在一个统一的中央节点,集中存放所有已登录的用户数据,各省的SSO 平台在用户需要登录时通过将用户重定向到中央SSO 平

台完成登录操作。具体流程参见下文中的用户登录、业务订购/点播和用户签退流程说明。


四、相关数据说明

1、SyncOrderRelationReq

<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns: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>
<TransactionID xmlns="http://www.monternet.com/dsmp/schemas/">00110338785301</TransactionID>该消息编号
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<SyncOrderRelationReq xmlns="http://www.monternet.com/dsmp/schemas/">
<Version>1.5.0</Version>该接口消息的版本号
<MsgType>SyncOrderRelationReq</MsgType>消息类型
<Send_Address>发送方的地址
<DeviceType>0</DeviceType>设备类型0:DSMP
<DeviceID>0011</DeviceID>设备编号
</Send_Address>
<Dest_Address>接收方的地址 使用用户标识当使用用户和计费用户为同一用户的时候,FeeUser_ID和DestUser_ID的值相同。
<DeviceType>400</DeviceType>设备类型400:SP
<DeviceID>0</DeviceID>设备编号
</Dest_Address>
<FeeUser_ID>计费用户标识
<UserIDType>1</UserIDType>用户标识类型1:用手机号标识
<MSISDN>13912345678</MSISDN>用户手机号
<PseudoCode></PseudoCode>用户伪码
</FeeUser_ID>
<DestUser_ID>使用用户标识
<UserIDType>1</UserIDType>用户标识类型1:用手机号标识
<MSISDN>13912345678</MSISDN>用户手机号
<PseudoCode></PseudoCode>用户伪码
</DestUser_ID>
<LinkID>SP</LinkID>临时订购关系的事务ID
<ActionID>2</ActionID>服务状态管理动作代码,具体值如下:1: 开通服务;2: 停止服务;3: 激活服务;4: 暂停服务;
<ActionReasonID>1</ActionReasonID>

ActionReasonID:产生服务状态管理动作原因的代码,具体值如下:1:用户发起行为产生服务状态管理动作原因的代码,具体值如下:
1:用户发起行为
2:Admin&1860发起行为
3:Boss停机
4:Boss开机
5:Boss过户
6:Boss销户
7:Boss改号
8:扣费失败导致的服务取消
9:其他

<SPID>419613</SPID>SP的企业代码
<SPServiceID>-LTYLBY</SPServiceID>SP中该服务的服务代码,标示每一种业务的内容,并也叫计费代码,业务代码
<AccessMode>3</AccessMode>服务的访问方式3:SMS 2:WAP 1:WEB
<FeatureStr>MTA2NjIxNDQgVERBRA==</FeatureStr>服务订购参数,用BASE64编码
</SyncOrderRelationReq>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


2、SyncOrderRelationResp
<SOAP-ENV:Envelope
xmlns: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:TransactionID xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">
<%=TransactionID %>
</dsmp:TransactionID>该消息编号
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<dsmp:SyncOrderRelationResp xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">
<MsgType>SyncOrderRelationResp</MsgType>
<Version><%=Version %></Version>该接口消息的版本号,本次所有的接口消息的版本都为“1.5.0
<hRet><%=hRet %></hRet>
</dsmp:SyncOrderRelationResp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

3、取消服务请求包
反向取消流程描述:
反向取消是从SP发起的取消流程,MISC在处理来自SP的取消消息的时候,其处理流程和来自其他网元的消息一样处理,流程如下:
(0) SP代替用户,向MISC发起反向取消请求UnSubscribeServiceReq并等待MISC处理;
(0) MISC对消息中的来源地址、企业代码进行鉴权,判断是否允许该SP进行反向取消;
(0) 接入鉴权成功后,再进行用户鉴权和订购关系鉴权,判断用户状态是否正确以及是否存在订购关系;
(0) 上面鉴权成功后,MISC向SP发送订购关系同步请求包SyncOrderRelationReq;
(0) SP收到同步请求后,对订购请求做相应的取消处理,并返回订购关系同步应答SyncOrderRelationResp;
(0) MISC收到应答后,判断应答值是否为0。如果应答值为0,则在MISC中取消订购关系,并给SP返回成功的反向取消处理应答包UnSubscribeServiceResp;如果应答值不为0,则

不取消订购关系,同时给SP返回不成功的反向取消应答包UnSubscribeServiceResp;
(0) SP如果收到MISC的错误响应,则说明取消失败,SP必须对这个失败消息做相应处理,比如把已取消的订购关系恢复等等;
(0) 如果收到MISC的正确响应,则SP可以不做任何处理;

<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns: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>
<TransactionID xmlns="http://www.monternet.com/dsmp/schemas/" xsi:type="xsd:string">9130020301801050</TransactionID>该消息编号
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<UnSubscribeServiceReq xmlns="http://www.monternet.com/dsmp/schemas/">
<Version>1.5.0</Version>
<MsgType>UnSubscribeServiceReq</MsgType>消息类型
<Send_Address>发送方的地址
<DeviceType>400</DeviceType>
<DeviceID>913002</DeviceID>
</Send_Address>
<Dest_Address>接收方的地址
<DeviceType>0</DeviceType>
<DeviceID>0024</DeviceID>
</Dest_Address>
<FeeUser_ID>计费用户标识
<UserIDType>1</UserIDType>见下面的定义
<MSISDN>13805002424</MSISDN>用户手机号
<PseudoCode />
</FeeUser_ID>
<DestUser_ID>使用用户标识当使用用户和计费用户为同一用户的时候,FeeUser_ID和DestUser_ID的值相同。
<UserIDType>1</UserIDType>
<MSISDN>13805002424</MSISDN>
<PseudoCode />
</DestUser_ID>
<Service_ID>服务标识
<ServiceIDType>1</ServiceIDType>
<SPID>913002</SPID>
<SPServiceID>-TQAAU</SPServiceID>
<AccessNo />
<FeatureStr />

</Service_ID>
<FeatureStr />
</UnSubscribeServiceReq>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

取消服务回应包
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns: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:TransactionID xmlns:dsmp="http://www.monternet.com/dsmp/schemas/">9130020301801050</dsmp:TransactionID>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<UnSubscribeServiceResp xmlns="http://10.1.2.122/misc/dsmp.xsd">
<Version>1.5.0</Version>
<MsgType>UnSubscribeServiceResp</MsgType>
<hRet>0</hRet>返回值:见下文定义
</UnSubscribeServiceResp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

4、返回值定义

在HTTP 通信时的状态码请参见HTTP/1.1 协议中规定的状态码值,不包含在本
规范的返回值统一定义中。
具体描述如下:
0 : 成功
1 : 未知错误
2-99:保留
4000-4999 为MISC 与SP 之间的接口消息中的错误代码:
4000: 无效的msgtype
4001: 无效的action_id;
4002: 无效的action_reasonid;
4003: 无效的SP ID
4004: 无效的serviceID
4005: 无效的pseudocode
4006: 无效的accessmode
4007: MISC 同步开通服务,但SP 端已存在订购关系,且状态为开通
4008: MISC 同步开通服务,且SP 端不存在订购关系,但开通服务失败
4009: MISC 同步开通服务,但SP 端已存在订购关系, 且状态为暂停
4010: MISC 同步停止服务, 且SP 端存在订购关系, 但取消服务失败
4011: MISC 同步停止服务, 但SP 端不存在订购关系
4012: MISC 同步暂停服务, 且SP 端存在订购关系, 但暂停服务失败
4013: MISC 同步暂停服务, 但SP 端不存在订购关系
4014: MISC 同步暂停服务, 但SP 端已存在订购关系, 且状态为暂停
4015: MISC 同步激活服务, 但SP 端已存在订购关系, 且状态为开通
4016: MISC 同步激活服务, 但SP 端不存在订购关系
4017: MISC 同步激活服务, 且SP 端存在订购关系, 但激活服务失败
9000-9999 为系统级错误:
9000: 系统磁盘读写错误
9001: 网络异常
9002: 网络错误
9003: 业务网关忙,业务网关缓存
9004: 业务网关忙,并且业务网关缓冲区满,MISC 缓存,并暂时不要发送消息,
等待一段时间重试。
9005: MISC 忙,MISC 缓存
9006: MISC 忙,并且MISC 缓冲区满,业务网关缓存,并暂时不要发送消息,等待一段时间重试。
9007: 业务网关超过限制的流量
9008: MISC 异常,并不可用
9009: 业务网关异常,并不可用
9010: 该业务网关没有权限调用该接口消息
9011: MISC 没有权限发送该接口消息给业务网关
9012: 版本不支持
第 6 页
MISC SP 业务反向接口
9013: 消息类型不对,系统不支持
9014: 验证错误,无法解析SOAP 和XML 结构、缺少必须存在的字段,或者消息,格式不正确
9015: 拒绝消息,服务器无法完成请求的服务

5、DeviceType 定义
设备类型
0:DSMP
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

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

7、UserIDType 定义
用户标识类型
1:用手机号标识
2:用伪码标识
3:两者同时标识

8、SPType
SP业务种类
1:所有的SP
2:提供短信服务的SP
3:提供WAP服务的SP
4:提供MMS服务的SP
5:提供KJAVA服务的SP
6:提供MAIL服务的SP
7:提供LBS服务的SP
8:提供WWW服务的SP
9~:扩展

9、ServiceIDType
服务类型的标识方式:
1:SPID+SPServiceID
2:AccessNo+FeatureStr


五、MISC对MO的业务匹配处理流程说明
处理说明:
1、SP进行业务申请时,按照不同的业务类型填写业务指令,根据业务类型的不同,可能存在“订购指令、取消指令、点播指令和普通MO”4种指令模式,设置指令时,需要指

定指令对应的发送号码(长号码)和指令内容,并可分别指定对发送号码和指令内容是否需要做精确匹配。
精确匹配的意思是指只有当所匹配内容和所设置的指令需要完全相同(包括长度也一样)时,才算匹配。例如如果设置了发送号码为“800101”,则只有当用户发送一条MO到

“80010123”时,将不会匹配上“800101”的那条指令;只有发往“800101”的指令才会被匹配上。
【注】对于同一种指令模式,每个服务可以设置多条,例如一个服务可以设置5条订购指令和5条取消指令,目前MISC可以支持超过5条的指令,但是从方便管理的角度考虑,对于同

一条模式的指令,建议SP设置时不要超过5条。
2、用户的MO短信由两部分构成:发送号码和发送的内容,再加上业务申请时设置的匹配模式,这三样共同构成了匹配时的依据。
3、当一条MO到MISC进行鉴权时,MISC先对发送号码(长号码)进行匹配,按照最大匹配+精确匹配的原则进行。如果有匹配成功的,则取出对应业务代码和指令类型;如果匹

配不上,则鉴权失败,该MO将不能发给SP。
4、在上一步匹配出来的列表中,再对指令内容进行匹配,也是按照最大匹配+精确匹配的原则进行。如果有能匹配上的结果,则取出对应的业务代码和指令类型;如果没有能

对应上的匹配结果,则取Service ID返回空值,同时通知短信网关将此条短信当作普通MO向SP转发。
5、SP在填写MO定购指令是尽量避免有嵌套的指令(例如同时存在“888801”和“8888011”的AccessNO)。
6、对于匹配成功的指令,MISC根据匹配出的指令的模式不同,处理方式如下:
?对于订购指令,则MISC将检查该用户是否已订购该服务,如果没有订购,则MISC将会完成订购,同时会将用户MO中的内容通过用户订购关系数据同步接口(Provision接口

)传送给SP,在Provision接口中的FeatureStr字段中将会有用户MO的长号码和指令内容,长号码和指令内容之间将以空格符分隔。同时MISC会通知短信网关这是一条订购指令,短

信网关将不向SP转发该MO。
如果该用户已订购该服务,则对于包月类服务,MISC会将该MO当作普通MO向短信网关返回鉴权成功的结果,通知短信网关将此条短信当作普通MO向SP转发;对于定制包月类服务,

则MISC会将该MO当作点播类型的MO向短信网关返回鉴权成功的结果,通知短信网关将此条短信当作点播MO向SP转发。
?对于取消指令,则MISC将检查该用户是否已订购该服务,如果已经订购,则MISC将会完成取消,同时会将用户MO中的内容通过用户订购关系数据同步接口(Provision接口

)传送给SP,在Provision接口中的FeatureStr字段中将会有用户MO的长号码和指令内容,长号码和指令内容之间将以空格符分隔。
如果该用户未订购该服务,则MISC会向短信网关返回鉴权失败,短信网关将不会向SP转发该MO。
?对于点播指令,MISC需要先判断该业务是定制点播类业务还是普通的点播类业务
1)对于定制点播类业务,需要判断用户是否已订购该服务,如果已订购,则MISC会生成临时订购关系(LinkID),同时向短信网关返回鉴权成功,并将LinkID返回给短信网

关,由短信网关将该MO作为点播MO向SP转发;如果用户未订购,则MISC只是简单向短信网关返回鉴权成功的响应,通知短信网关将此条短信当作普通MO向SP转发。
2)对于点播类业务,则MISC会直接生成临时订购关系(LinkID),同时向短信网关返回鉴权成功,并将LinkID返回给短信网关,由短信网关将该MO作为点播MO向SP转发。
?对于普通MO短信,MISC向短信网关返回鉴权成功的响应,通知短信网关将此条短信当作普通MO向SP转发。
范例说明:
seq AccessNO FeatureStr ANCheckFlag FSCheckFlag
1 8888 xw 1 0
2 888801 xw 0 0
3 888801 xw1 0 1
4 8888 01xw 1 1
5 8888 (null) 0 0 (HELP)
【注】AccessNO表示MO的发送号码
FeatureStr表示指令内容
ANCheckFlag表示对AccessNO是否使用精确匹配
FSCheckFlag表示对指令内容是否使用精确匹配

针对上面的设置,
用户发送 xw1到8888011我们匹配第3条记录
用户发送 xw01到888801我们将匹配到第2条记录(先最长匹配接入号)
用户发送01xw到888802我们匹配到第5条记录(不会匹配到第4条记录,因为第4条记录的AccessNO是精确匹配)
用户发送01xw到8888我们匹配到第4条记录
用户发送 xw01到8888我们匹配第1条记录
用户发送 A到8888我们匹配第5条记录,


六、业务指令举例

业务类别业务名称IODPUSHSTK产品描述
业务代码点播指令计费类型价格返回条数业务代码计费类型价格发送频率业务代码

计费类型价格返回条数
应用服务哈妮HY发自然语句到XXX包月5元1通过自然语言和虚拟主

持“哈妮”交流
聊天帅哥靓妹LT发A到XXX按条0.2元1用户注册分配ID号,通

过ID号找聊友匿名聊天交友
测试其实不懂你的心CS发P到XXX包月7元1心理测试大全
游戏风月俏佳人JR法M到XXX包月7元1恋爱角色游戏
游戏非常告白GB法GB到XXX按条0.2元1,情感故事
测试识情男女NV法NV到XXX按条0.2元1爱情测试游戏
传情语鱼和水的故事YS法YS到XXX按条0.1元1,2传情语
测试官运财运桃花运YU法YU到XXX按条0.2元1生日测试
游戏女儿国YG法YG到XXX按条0.2元1新西游记角色游戏
游戏向左走向右走ZY法ZY到XXX按条0.2元1,2漫画短信故事
游戏心上人XR法XR到XXX按条0.3元1通过对方的留言,猜他的手机号
测试星星知我心XX法XX到XXX按条0.2元1,3星座测试
易程塔罗牌TL法TL到XXX包月7.0元1,3塔罗牌短信版
易程姓名与人生XM法XM到XXX按条0.4元1,4姓名测试
游戏前世今生QS法QS到XXX按条0.5元1,4生日游戏

——即只要是上面的字母开头的发送到相应端口开头的,移动都认为存在点播或者定制关系,具体怎么区别是什么业务,有provision接受到的包来处理,目前基本已经做到。
——由于移动已经没有免费代码,即原来的free等都不能使用,故不再有错误提示,如果已经设计有的,则是扣费信息;
——只要用户存在了定购关系,所有的下行都必须使用计费代码下行,定制业务则会扣费,包月业务用计费代码下发,则移动不会将其当作沉默用户


以上是总结SMS开发经验所得的重点内容,由于是刚接触几个月,有很多细节不能包括,详细的内容可以察看相关的文档。还有理解上肯定存在很多误区,大家可以到我的BLOG交流

。欢迎转载,但注明出处。blog.csdn.net/cutemose

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics