|
开发过程遇到的几个难点：
1、序列号的定义 SGIP1.2 第7页 序列号的定义 写道
序列号分成三部分，每部分为一个32位整数，第一部分表示命令源节点的编号，第二部分表示命令产生的日期和时间(网关系统中的任何命令的保存时间都不应该超过一年)，格式为十进制的mmddhhmmss,比如11月20日20时32分25秒产生的命令，其第二部分为1120203225;第三部分由0开始，循环进位，直到进位满了之后再清零，重新开始计数。接收方在返回应答时，应答的序列号必须和相对应的命令的序列号相同。
SGIP1.2 第7页 源节点编号规则 写道
在整个网关系统中，所有的通信节点(SMG、GNS、SP和SMSC)都有一个唯一的数字编号，不同的SP或SMSC或SMG或GNS编号不能相同，编号由系统管理人员负责分配。编号规则如下：
SMG的编号规则：1AAAAX SMSC的编号规则：2AAAAX SP的编号规则：3AAAAQQQQQ GNS的编号规则：4AAAAX 其中，AAAA表示四位长途区号(不足四位的长途区号，左对齐，右补零)，X表示1位序号，QQQQQ表示5位企业代码。 由于java只有byte,short,int,long等数据类型，不像c/c++那样，有unsigned int，所以java语言中普通的int变量不能存储如此大的数据 比如说，我所在的城市济南,区号为0531,公司的企业代码为41211,按照源节点编码规则为3053141211,共10位，而int变量的范围为-2147483648~2147483647 int srcnode = 3053141211;显然不能通过编译因为已经超过int的表示范围。 还好，Java提供了超大整型类BigInteger int srcnode =new BigInteger("3053141211").intValue(); //源节点编号 byte[] srcnodeBytes = IntToBytes4(srcnode); 用于Java采用补码srcnode的字节长度为5,不要使用toByteArray()方法获得字节数组，应单独编写一个方法用于int转byte[]的方法，注意必须以网络字节序的方式转换，即高位放在低地址，低位放在高地址
/** * 将int转换为byte数组 * * @param i 待转换的int变量 * * @return byte[] 转换后的byte数组 */ public static byte[] intToBytes4(int i) { byte[] mybytes = new byte[4]; mybytes[3] = (byte) (0xFF & i); mybytes[2] = (byte) ((0xFF00 & i) >> 8); mybytes[1] = (byte) ((0xFF0000 & i) >> 16); mybytes[0] = (byte) ((0xFF000000 & i) >> 24); return mybytes; }
2、int转byte[]及字节序 在将int转为byte[]，须注意字节的顺序。字节顺序分网络字节序和本地字节序，网络字节顺序是TCP/IP中规定好的一种数据表示格式，它与具体的CPU类型、操作系统等无关，从而可以保证数据在不同主机之间传输时能够被正确解析。网络字节顺序采用big endian排序方式。sgip1.2规定数据传输采用网络字节顺序Big endian(将高字节存储在低地址处，将低字节存储在高地址处)。具体转换及移位操作的使用见http://blog.csdn.net/Mailbomb/archive/2008/05/30/2496168.aspx
3、重复收到联通上行(MO) 重复收到联通上行困扰了我好几天，仔细检查命令的格式都没有错误，上网搜索在csdn看到一个遇到同样问题的帖子，加他QQ，问他这个问题时一直不肯告诉我原因，真的太小气了。想想也是，说不定他解决这个问题费了好多的时间和精力，怎么能让自己辛苦劳动的结果让别人拿去呢，真没有开源精神，鄙视下! 最后实在找不出原因，打电话请济南联通的张工在后台跟踪下，最终找出原因: 在SMG向SP递交上行时，SP收到上行必须给SMG一个deliver_resp应答，且应答的序列号必须和相对应的命令的序列号相同。 问题出在我返回了应答，但是返回的应答序列号和之前的上行的deliver命令的序列号不同，SMG认为SP没有收到上行，所以才会重复发送上行给SP.
4、收到用户的定购命令但无法下行(MT) 实施SPMS系统后，凡是订购（定制）业务都需要SPMS给用户发送确认短信，得到用户确认后，才形成临时订购关系；当SP的订购成功欢迎短信通知成功下发后，才生成正式订购（定制）关系。 根据“联通在信”SGIP1.2协议修改部分说明，在给用户下发短信时，必须附加linkID且SP下发时UserCount必须填写1，否则视为业务非法包处理。 Submit命令中Reserve字段说明:
该Reserve字段为8个字节的保留字段；现将该字段作为MO和MT之间一一对应的LinkID来用。该Reserve字段的值（LinkID）由SPMS业务鉴权平台生成，传给SMG。SPMS将对MO所引起的下发MT进行Reserve（LinkID)值的匹配校验。 SP收到SMG网关发送的MO包后，要将MO中的Reserve字段原封不动拷贝出，并赋到该MO所引起的MT（1个或多个）包的Reserve字段中。该操作适用于进行定制命令、退订命令、MO所引起的MT点播之间的对应关系。如果SP不填，SPMS将因为匹配关系不合法，进行过滤。没有成功下发的原因就是因为没将MO中的Reserve字段赋值到Submit的Reserve字段造成的。
SMG返回的错误码及含义
1 消息结构错
2 命令字错误 3 消息序列号重复 4 消息长度错 5 资费代码错 6 超过最大信息长 7 业务代码错 8 流量控制错（user_phone单填写CDMA号码不在白名单中或charge_phone和user_phone填写的CDMA号码不在白名单） 9 本网关不负责此计费号码（如意通和外省号码） 10 Src_ID错（手机因关机或内存满消息超时删除返回的状态报告） 11 CorpID错(如是MT消息出现很多，可能是他的提交submit消息接口与回状态报告的接口冲突，建议SP不要使用手机上行接口来下发SUBMIT消息；还有一种情况是corp_id填写错误) 12 计费地址错（user_phone单填写GSM号码不在白名单中或charge_phone和user_phone填写的GSM号码不在白名单） 13 目的地址错 14～49 扩展 23(英斯克定义) 路由错误。路由不存在，指消息路由的节点在路由表中不存在 24(英斯克定义) 黑名单用户。计费号码无效，鉴权不成功时反馈的错误信息 40(英斯克定义) 网关对如意通用户进行拦截 50(英斯克定义) 短消息内容非法 51 尚未建立连接 52 尚未成功登录 53 发送消息失败 54 超时未接收到响应消息（一般是tp_udhi一项填写不对，应该填写0） 55 等待状态报告超时 56 用户鉴权时用户状态不正常（charge_phone不在白名单） 60 保留 61 有效时间已经过期（charge_phone和user_phone填写的GSM号码不在白名单） 62 定时发送时间已经过期 63 不能识别的FeeType 64 发送服务源地址鉴权失败 65 发送服务目的地址鉴权失败 66 接收服务源地址鉴权失败(手机内存满或关机等待下发已经到达10条后，SP再发就会出现此错误) 67 接收服务目的地址鉴权失败 68 用户鉴权失败 69 此用户为黑名单用户 70 网络断连或目的设备关闭接口 71 超过最大节点数 72 找不到路由 73 等待应答超时 74 送SCP失败 75 送SCP鉴权等待应答超时 76 信息安全鉴权失败 77 超过最大Submit提交数 78 SPID 为空 79 业务类型为空 80 CPCode错误 81 发送接收接口重复 82 循环路由 83 超过接收侧短消息MTU 84 送DSMP重发失败 85 DSMP系统忙重发 86 DSMP系统忙，且缓存满重发 87 DSMP流控重发 88 流控错误，流量超过最大限制 89 90 SGIP消息等待处理 91 SGIP协议状态报告请求标识错误 92 SGIP协议MT标识错 93 SGIP协议SP节点编号错 94 没有配置账号 101 /* 定购业务失败 */ 102 /* 退定业务失败 */ 103 /* 非法SP */ 104 /* 非法用户 */ 105 /* 用户未定购此项业务，鉴权失败 */ 106 /* 非法费用，鉴权失败 */ 107 /* 重复包月话单 */ 108 /* 非法指令*/ 109 /* 非法业务代码*/ 110 /* 已定购该业务 */ 111 /*--需要用户回复的定制信息--*/ 112 /*--需要用户回复的定制信息--*/ 113 /*--需要用户回复的定制信息--*/ 114 /*--用户回复的定制信息不存在--*/ 115 /*--SP回复的定制信息不存在--*/ 116 /* 用户未点播此项业务，鉴权失败 */ 117 /* 等待用户作二次确认*/ 118 /* 等待sp作定制确认*/ 119 /* sp定制确认返回ERROR定制不成功要求复位*/ 121 /* 下行对应多个目的号码*/ 199 /* SPMS 修正了SUBMIT */ 122 /* 非法SERVICE */ 123 /* 非法SERVICE */
返回码更新，见下表
|
|
|
