白话CMPPSGIP

8次阅读

共计 3219 个字符,预计需要花费 9 分钟才能阅读完成。

白话 CMPP、SGIP

我们都知道在国内,有 3 家运营商(中国联通,中国移动,中国电信),而这三家运营商也是各自使用的自己的协议,不过却是大同小异,它们都是基于我们前两篇(白话短信协议,白话彩信协议)介绍的短彩信协议,不过是扩展了一些运营商特有信息而已

那接下我我们就挑两个介绍一下,移动的 CMPP 协议,以及联通的 SGIP 协议

CMPP 协议

CMPP 也有多种版本,这里我们以 CMPP2.0 为例来介绍,CMPP 协议中定义了多种消息类型,主要包括连接消息(Connect Message)、提交消息(Submit Message)、送达消息(Deliver Message)、终端消息(Terminate Message)、心跳消息(Active Test Message)

这里我们主要介绍两个较复杂的 Submit Message 以及 Deliver Message,因为这两个消息是和我们短彩信内容相关的,其它的消息类型看名称就能看得出,是一些功能性的消息,我们这里就略过了

CMPP 协议也有信息头和信息体

信息头里包含两个信息 command_id 和 sequece_id,它们各占 4 个字节,我们这里特别解释一下 command_id,command_id 代表了消息类型,比如 0x00000004 表示是一个 Submit Message, 0x00000005表示一个 Deliver Message,其它消息也有一个 command_id 对应,我们就不一一列举了;sequence_id 表示流水号,我们可以先不用关心

我们接着说信息体,先给你列出信息体里包含的信息:msg_id, pk_total, pk_number, registered_delivery, msg_level, service_id, fee_user_type, fee_terminal_id, tp_pid, tp_udhi, msg_fmt, msg_src, fee_type, fee_code, val_id_time, at_time, src_id, dest_terminal_id, msg_length, msg_content, reserve

我们开始的时候提到过,CMPP 是基于短信协议扩展的,那这是怎么体现的呢?

老样子,我们先来回顾一下短信协议是什么样子的:

那我们上面那么多信息是放到 PDU 哪个部分的呢?其实我们上面的信息并不是放到 PDU 中间的,而是放到 PDU 前面的,那我们一个 CMPP 协议组成(这里列举的是 Submit Message)就是这样的:

知道了 CMPP 的样子,我们回过来看一下上面有很多信息,我们先不用关心所有的值,我们来看一下和我们短彩信内容有关的:pk_total, pk_number, tp_pid, tp_udhi, msg_fmt, msg_length, msg_content,其中,msg_content 看名称就知道是我们的消息内容了,也就是我们 PDU 的内容

接着我们来看剩下的值表示什么

pk_total, pk_number:还记得我们讲短信协议的时候有提到,长短信会拆分成多条吗?我们当时讲到,如果是长短信,UDH 中会带有短信的分段信息(refNr,totalNumberOfSms,seqNr),我们 CMPP 协议中也需要指定,其 pk_total=totalNumberOfSms,pk_number=seqNr

tp_pid:在短信协议中用来表示上层协议类型,在我们 CMPP 协议里的的值为 0,我们可以先不用关心

tp_udhi:如果我们 PDU 中 UDH 有值,该值为 1,反之则为 0

msg_fmt:我们在讲短信协议时有提到过 DCS,用来指示如何处理 UD,就是这个值了

msg_length:看名称就知道是 PDU 的长度

接着我们来看一下 Deliver Message

Deliver Message 和 Submit Message 一样,包含的内容少了计费相关的信息:msg_id, dest_id, service_id, tp_pid, tp_udhi, msg_fmt, src_terminal_id, registered_delivery, msg_length, msg_content, reserve,和 Submit Message 的组成一样,我们这里就不重复了

这里补充一点,我们可以看到,Deliver Message 中少了 pk_total, pk_number,所以在 Deliver Message 中,我们的长短信信息就需要从 UDH 中提取了

好了,Submit Message 和 Deliver Message 中所有和短彩信消息内容相关的信息我们就介绍完了

SGIP 协议

SGIP 也有多种版本,这里我们以 SGIP1.2 为例来介绍,SGIP 协议中也定义了多种消息类型,主要包括连接消息(Bind Message)、提交消息(Submit Message)、送达消息(Deliver Message)、终端消息(Unbind Message)、报告消息(Report Message)

和 CMPP 一样,我们也是主要介绍 Submit Message 以及 Deliver Message,那我们来看协议的信息头和信息体

信息头里也包含两个信息 command_id 和 sequece_number,command_id 占 4 个字节,command_id 同样代表了消息类型,比如 0x00000003 表示是一个 Submit Message, 0x00000004表示一个 Deliver Message,其它消息也有一个 command_id 对应,我们也就不一一列举了;sequece_number 和 CMPP 不同,sequece_number 也表示流水号,不过占用 12 个字节,我们也先不用关心

我们接着说信息体,同样列出信息体里包含的信息:sp_number, charge_number, user_number, crop_id, service_type, fee_type, fee_value, given_type, agent_flag, more_late_to_mt_flag, priority, expire_time, schedule_time, report_flag, tp_pid, tp_udhi, message_coding, message_type, message_length, message_content, reserve

同样我们还是看一下 SGIP 协议组成(这里也是 Submit Message)是什么样子:

我们来看一下和我们短彩信内容有关的:tp_pid, tp_udhi, message_coding, message_length, message_content

相比于 CMPP,SGIP 没有 pk_total, pk_number,所以我们长短信信息只在 UDH 中,tp_pid, tp_udhi 同 CMPP 一样,message_coding 同 CMPP 的 msg_fmt 一样,message_length, message_content 同样与 CMPP 一样

可以看出,SGIP 和 CMPP 大同小异,当然,它们的编码顺序上会有些先后不同,这里就不详细介绍了

同样,接着我们再来看一下 Deliver Message

Deliver Message 和 Submit Message 一样,包含的信息:sp_number, user_number, tp_pid, tp_udhi, message_coding, msg_length, msg_content, reserve,和 Submit Message 的组成一样,我们这里也就不重复了

这里我们没有解释所有的值,也没没有具体列出每个字段占用的字节和编码方式,因为这些相比于短彩信的编码会简单很多,并且我们主要是目的是介绍 CMPP、SGIP 包含的信息,以及了解其与短信协议的关系

当然,如果你对详细的编码有兴趣,可以到 SMSSP 查看

后面的内容我们就会介绍基于 netty 的短彩信网关 SMSSP

正文完
 0