CMPP3.0 長簡訊實現方案
長簡訊息:是指超過70個漢字,140個位元組的資訊內容
一、CMPP協議相關欄位分析
CMPP協議具體部分請參考《中國移動網際網路簡訊閘道器介面協議(V3.0.0).doc》
CMPP_SUBMIT訊息定義(SP--->SMG)
欄位名 |
位元組數 |
屬性 |
描述 |
Msg_Id |
8 |
Unsigned Integer |
資訊標識。 |
Pk_total |
1 |
Unsigned Integer |
相同Msg_Id的資訊總條數,從1開始。 |
Pk_number |
1 |
Unsigned Integer |
相同Msg_Id的資訊序號,從1開始。 |
Registered_Delivery |
1 |
Unsigned Integer |
是否要求返回狀態確認報告: 0:不需要; 1:需要。 |
Msg_level |
1 |
Unsigned Integer |
資訊級別。 |
Service_Id |
10 |
Octet String |
業務標識,是數字、字母和符號的組合。 |
Fee_UserType |
1 |
Unsigned Integer |
計費使用者型別欄位: 0:對目的終端MSISDN計費; 1:對源終端MSISDN計費; 2:對SP計費; 3:表示本欄位無效,對誰計費參見Fee_terminal_Id字 段。 |
Fee_terminal_Id |
32 |
Octet String |
被計費使用者的號碼,當Fee_UserType為3時該值有效,當Fee_UserType為0、1、2時該值無意義。 |
Fee_terminal_type |
1 |
Unsigned Integer |
被計費使用者的號碼型別,0 |
TP_pId |
1 |
Unsigned Integer |
GSM協議型別。詳細是解釋請參考GSM03.40中的9.2.3.9。 |
TP_udhi |
1 |
Unsigned Integer |
GSM協議型別。詳細是解釋請參考 GSM03.40中的9.2.3.23,僅使用1位,右對齊。 |
Msg_Fmt |
1 |
Unsigned Integer |
資訊格式: 0:ASCII串; 3:簡訊寫卡操作; 4:二進位制資訊; 8:UCS2編碼; 15:含GB漢字。。。。。。 |
Msg_src |
6 |
Octet String |
資訊內容來源(SP_Id)。 |
FeeType |
2 |
Octet String |
資費類別: 01:對“計費使用者號碼”免費; 02:對“計費使用者號碼”按條計資訊費; 03:對“計費使用者號碼”按包月收取資訊費。 |
FeeCode |
6 |
Octet String |
資費程式碼(以分為單位)。 |
ValId_Time |
17 |
Octet String |
存活有效期,格式遵循SMPP3.3協議。 |
At_Time |
17 |
Octet String |
定時傳送時間,格式遵循SMPP3.3協議。 |
Src_Id |
21 |
Octet String |
源號碼。SP的服務程式碼或字首為服務程式碼的長號碼, 閘道器將該號碼完整的填到SMPP協議Submit_SM訊息相應的source_addr欄位,該號碼最終在使用者手機上顯示為短訊息的主叫號碼。 |
DestUsr_tl |
1 |
Unsigned Integer |
接收資訊的使用者數量(小於100個使用者)。 |
Dest_terminal_Id |
32*DestUsr_tl |
Octet String |
接收簡訊的MSISDN號碼。 |
Dest_terminal_type |
1 |
Unsigned Integer |
接收簡訊的使用者的號碼型別,0:真實號碼;1:偽碼。 |
Msg_Length |
1 |
Unsigned Integer |
資訊長度(Msg_Fmt值為0時:<160個位元組;其 它<=140個位元組),取值大於或等於0。 |
Msg_Content |
Msg_length |
Octet String |
資訊內容。 |
LinkID |
20 |
Octet String |
點播業務使用的LinkID,非點播類業務的MT流程不使用該欄位。 |
紅色部分表示髮長簡訊要更改的欄位
洋紅色部分表示髮長簡訊可以更改或者不更改的欄位
在cmpp協議裡,CMPP_SUBMIT訊息定義中有相應的引數配置:
- TP_udhi :0代表內容體裡不含有協議頭資訊 1代表內容含有協議頭資訊(長簡訊,push簡訊等都是在內容體上含有頭內容的)當設定內容體包含協議頭,需要根據協議寫入相應的資訊,長簡訊協議頭有兩種:
- 6位協議頭格式:05 00 03 XX MM NN
a) byte 1 : 05, 表示剩餘協議頭的長度
b) byte 2 : 00, 這個值在GSM 03.40規範9.2.3.24.1中規定,表示隨後的這批超長簡訊的標識位長度為1(格式中的XX值)。
c) byte 3 : 03, 這個值表示剩下簡訊標識的長度
d) byte 4 : XX,這批簡訊的唯一標誌,事實上,SME(手機或者SP)把訊息合併完之後,就重新記錄,所以這個標誌是否唯一併不是很 重要。
e) byte 5 : MM, 這批簡訊的數量。如果一個超長簡訊總共5條,這裡的值就是5。
f) byte 6 : NN, 這批簡訊的數量。如果當前簡訊是這批簡訊中的第一條的值是1,第二條的值是2
例如:05 00 03 39 02 01
- 7 位的協議頭格式:06 08 04 XX XX MM NN
a) byte 1 : 06, 表示剩餘協議頭的長度
b) byte 2 : 08, 這個值在GSM 03.40規範9.2.3.24.1中規定,表示隨後的這批超長簡訊的標識位長度為2(格式中的XX值)。
c) byte 3 : 04, 這個值表示剩下簡訊標識的長度
d) byte 4-5 : XX XX,這批簡訊的唯一標誌,事實上,SME(手機或者SP)把訊息合併完之後,就重新記錄,所以這個標誌是否唯一併不是很重要。
e) byte 6 : MM, 這批簡訊的數量。如果一個超長簡訊總共5條,這裡的值就是5。
f) byte 7 : NN, 這批簡訊的數量。如果當前簡訊是這批簡訊中的第一條的值是1,第二條的值是2
例如:06 08 04 00 39 02 01
二、實現程式碼(C#)
byte[] messageUCS2 = Encoding.BigEndianUnicode.GetBytes(MtMsg); int messageUCS2Len = messageUCS2.Length; int maxMessageLen = 140; if (messageUCS2Len > maxMessageLen) { int messageUCS2Count = messageUCS2Len / (maxMessageLen - 6) + 1; //長簡訊分為多少條傳送 byte[] tp_udhiHead = new byte[6]; tp_udhiHead[0] = 0x05; tp_udhiHead[1] = 0x00; tp_udhiHead[2] = 0x03; tp_udhiHead[3] =//0x0A; tp_udhiHead[4] = (byte)messageUCS2Count; tp_udhiHead[5] = 0x01; //預設為第一條 for (int i = 0; i < messageUCS2Count; i++) { tp_udhiHead[5] = (byte)(i + 1); byte[] msgContent; if (i != messageUCS2Count - 1) { //不為最後一條 msgContent =BIConvert.byteAdd(tp_udhiHead, messageUCS2, i * (maxMessageLen - 6), (i + 1) * (maxMessageLen - 6)); } else { msgContent = BIConvert.byteAdd(tp_udhiHead, messageUCS2, i * (maxMessageLen - 6), messageUCS2Len); } } } |
三、總結
以上是移動CMPP中長簡訊的實現方法,在聯通、電信簡訊協議中,實現方法一樣。
移動CMPP協議長簡訊方案:
- Msg_Fmt = 8 ;
Tp_Udhi = 1; - 可採用6位元組協議頭,也可採用7位元組協議頭,實測都通過。
- 6位元組協議頭:
- MsgContent的前三個位元組為:0x05, 0x00, 0x03(0x05表示後面還有5位元組,0x03表示後面還有3位元組)
- 第四個位元組為批號,合成同條長簡訊的小簡訊填一樣的值即可。(同時給同個號碼發多條長簡訊的要分不同長簡訊填寫);
- 第五個位元組為Pk_total的值,即這批簡訊的總條數。
- 第六個位元組為Pk_number的值,即這條簡訊在長簡訊中的序號,從1開始。。
- 7位元組協議頭:
- MsgContent的前三個位元組為:0x06, 0x08, 0x04(0x06表示後面還有6位元組,0x04表示後面還有4位元組)
- 第四、五個位元組為批號,合成同條長簡訊的小簡訊填一樣的值即可。(同時給同個號碼發多條長簡訊的要分不同長簡訊填寫);
- 第六個位元組為Pk_total的值
- 第七個位元組為Pk_number的值
- 6位元組協議頭:
- MsgContent 在第6或7位元組後加上要傳送的簡訊內容,記得要UCS2編碼的哦。
- Pk_total和Pk_number 可以不設定,如果要設定,就要分別跟TP_udhi的MM和NN欄位一致
聯通SGIP1.2協議長簡訊方案
只測試了6位元組協議頭的,方法與以上移動使用的6位元組協議頭一樣。
MessageCoding= 8 ;
Tp_Udhi = 1;
MessageContent前三個位元組為:0x05, 0x00, 0x03
第四個位元組為批號;
第五個位元組為這批簡訊的總條數;
第六個位元組這條簡訊在長簡訊中的序號,從1開始。
3、MessageContent在第6位元組後加上要傳送的簡訊內容的UCS2編碼
電信SMGP3協議長簡訊方案:
- 設定tlv欄位TP_udhi為0x01,表示訊息內容裡面包含訊息頭(也就是說含長簡訊頭)
-
內容前面需要增加6個欄位
- 位元組一:包頭長度,固定填寫0x05;
- 位元組二:包頭型別標識,固定填寫0x00,表示長簡訊;
- 位元組三:子包長度,固定填寫0x03,表示後面三個位元組的長度;
- 位元組四到位元組六:包內容:
- 位元組四:長訊息參考號,每個SP給每個使用者傳送的每條參考號都應該不同,可以從0開始,每次加1,最大255,便於同一個終端對同一個SP的訊息的不同的長簡訊進行識別;
- 位元組五:本條長訊息的的總訊息數,從1到255,一般取值應該大於2;
- 位元組六:本條訊息在長訊息中的位置或序號,從1到255,第一條為1,第二條為2,最後一條等於第四位元組的值。
-
例子:
05 00 03 00 02 01
05 00 03 00 02 02 -
你還需要設定PkTotal和PkNumber
這個欄位如果不設定並不影響使用者手機對簡訊的拼裝,但是會影響ismp的健權和計費,一組pktotal pknumber裡面的資料ismp是當一條簡訊健權和計費。
相關推薦
CMPP3.0 長簡訊實現方案
長簡訊息:是指超過70個漢字,140個位元組的資訊內容 一、CMPP協議相關欄位分析 CMPP協議具體部分請參考《中國移動網際網路簡訊閘道器介面協議(V3.0.0).doc》 CMPP_SUBMIT訊息定義(SP--->SMG) 欄位名 位元組數 屬性
cmpp2.0長簡訊的處理方案
長簡訊處理方案 上次寫過對簡訊傳送的處理,並沒有體現出對長簡訊的處理方案,在實際應用中發現了以下問題,對於簡訊長度超過指定的大小時會出現截短的現象. 原資訊地址:(裡面有原始碼,和相關的配置),主要對以下方法進行修改 1)這種方案是處理長簡訊的方式(可以實現向客戶端傳送的連
CMPP傳送長簡訊,我可以實現了 CMPP2長簡訊實現(java版)
辭職後我就在yiDong從事簡訊和群發的工作,從北京方面的專家哪裡學會了傳送簡訊,一開始只能傳送短簡訊,就是不超過140個字元,如果超過我就分割然後分成短的傳送。一直不能傳送超過140字元的。後來經過我閱讀了很多人帖子才實現,主要是看了下面的內容,然後修改了程式碼才實現的
Hadoop2.0 Namenode HA實現方案介紹及彙總
基於社群最新release的Hadoop2.2.0版本,調研了hadoop HA方面的內容。hadoop2.0主要的新特性(Hadoop2.0穩定版2.2.0新特性剖析): namenode federation: namenode在叢集規模大了之後會成為效能瓶頸,尤其是
CMPP3.0-超長簡訊
超長簡訊:簡訊內容超過70個漢字,提交給閘道器時候需要分成多條,但是使用者手機接收時候是一條(sp角度,手機發送長簡訊概念一樣)。 在cmpp協議裡,CMPP-_SUBMIT訊息定義中有相應的引數配置: TP_udhi :0代表內容體裡不含有協議頭資訊 1
CMPP3.0實現物聯網絡卡發簡訊遇到的問題
當下物聯網發展迅猛,物聯網絡卡可以接受簡訊指令,實現千里之外儘可掌控。本人做過一個這類專案,把相關經驗記錄下來,分享給需要的人。 物聯網絡卡通訊其實跟電話卡一樣,可以使用CMPP協議。不過由於物聯網絡卡位數為13位,未測試CMPP2.0是否支援,直接保險一點用
移動端html5頁面長按實現高亮全選文字內容的相容解決方案
最近需要給html5的WebAPP在頁面上實現一個複製功能:使用者點選長按文字會全選文字並彈出系統“複製”選單,使用者可以點選“複製”進行復制操作,然後貼上到AppStore搜尋對應的應用。之所以不是採用連結形式直接跳轉到AppStore對應應用是為了通過使用者的主動輸入關鍵詞搜尋給推廣的企業App
實時報表 T+0 的實現方案
一 問題背景 在報表的應用系統中,使用者越來越關注資料的實時性,希望最新發生的資料能在報表中體現出來,也就是我們常說的T+0場景, 以此及時輔助決策、驅動運營。 比如交通大資料應用的場景:需要結合實時資料瞭解車輛通行密度,合理進行道路規劃,同時根據歷史資料預測線路擁堵情況、
【外掛分享】 簡訊如何實現Destoonb2b_V6.0對接簡訊驗證碼
對接簡訊的時候發現一家簡訊公司,有些不錯的簡訊驗證碼的外掛,對接起來挺方便的,有需求的可以看一下。http://www.ihuyi.com/ 外掛說明本外掛系互億無線針對DestoonB2B_V6.0簡訊外掛開發,外掛內的所有檔案均為對原檔案的修改,如果你的系統經過二次開發,安裝本外掛之前,請仔細核對修改。
原創安卓手機QQ7.0登入介面動態背景視訊實現方案
qq7.0登入介面動態背景實現 qq7.0登入介面動態視訊背景實現 android動態視訊背景 android動態背景 分析qq7.0: 視訊在開啟登入介面就開始播放 了,而且期間無黑屏 而且是迴圈播放的 畫質問題這裡就不說了,這個看視訊源了。
網站二級域名用asp.net 2.0的實現方案
基本思路:1. 域名支援泛解析,即是指:把A記錄 *.域名.com 解析到伺服器IP,伺服器IIS中做繫結,繫結時主機頭為空;2. 為了實現完全的二級域,建兩個站點,一個為主站用,一個為使用者用,兩個站點目錄都指到一個同一網站目錄3. 在Web程式中或取URL來源中的二級域名主機頭,比如:abc.域名.co
安卓6.0請求許可權實現發簡訊打電話
安卓6.0的許可權申請有了變化,更加安全了,具體變化不再多說了, 很多許可權不再是簡單的在註冊清單裡註冊了。 找了一個工具類,使用起來還不錯。 Github https://github.com/a5533348/XPermission PermissionUtils.ja
米聯客(MSXBO)USB3.0 UVC攝像頭實現基於FT602Q晶片方案
USB3.0 UVC攝像頭實現基於FT602Q晶片方案 USB3.0介面晶片FT602Q支援UVC協議,可以很方便的實現一個US
《程式碼統計分析工具 4.0》多國語言實現方案
【翻譯工具】- PoEdit【軟體開發工具】- Code::Blocks- wxWidgets- GCC【程式碼示例】程式碼裡使用 _("string") 方式,將需要翻譯的字串標記起來,PoEdit工具會自動識別這些字串,自動生成 .po檔案,翻譯並儲存會生成 .mo 檔案。 wxArraySt
架構設計:資料服務系統0到1落地實現方案
本文原始碼:[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、基於業務 資料服務通常有很
vue2.0結合Element實現select動態控制input禁用
嘻嘻 [0 attr 折騰 解決 model utf del logs 今天有一個盆友問小穎,怎麽實現用select動態控制input禁用,也就是說,input默認是可編輯的,但是每當我選一次select,input就會變成禁用,雖然小穎不知道她為什麽這樣做,因為小
針對敲詐病毒(WanaCrypt0r2.0)的應對方案
補丁 處理 應對 敲詐病毒 wanacrypt0r 2.0 病毒背景 5月12日起,Onion、WNCRY兩類敲詐者病毒變種在全國乃至全世界大範圍內出現爆發態勢,中國大陸大量教育網用戶和企業用戶中招。 與以往不同的是,這次的新變種病毒添加了NS
Python error: Microsoft Visual C++ 9.0 is required 解決方案
compile blank 安裝ipython con pan code logs onf pre 換了新電腦,在使用python2.7 pip 安裝ipython時,報錯了 error: Microsoft Visual C++ 9.0 is required. Get
邊框0.5px的實現方法
pan web -i tran webkit css3 borde index html 原理: css3 的縮放 ----> transform: scale() 完整代碼如下: <!DOCTYPE html> <html lang
spark提交jar包時出現unsupported major.minor version 52.0錯誤的解決方案
模式 classname jdk版本 images pil 編譯器 就會 home spark 一、問題: 最近在spark集群上做一個項目,打包提交jar包時,出現了unsupported major.minor version 52.0的報錯,而在local模式