Sp sms development-Basic Knowledge

This is a rare topic, but I recently helped my friends do this. So I wrote something for beginners.
I. Prepare materials
There are many SP development materials on the website, but mainly the following documents:
1. misc1.6 SP subscription notification interface requirements
2. smpp Protocol
3366miscsystem SMS spaccess training (simplified version ).ppt
4. Detailed description of SSO platform access specifications in dsmp specifications v1.5.1.pdf
5. error codes available for SP viewing
6 Gbit/s sso in dsmp
7. Internet SMS Gateway Interface Protocol V3.0

Ii. Text Message Service Classification

There are two types of text message services: on-demand video services and customized services.
1. VOD service
There is no-before its service_id, such as ylsh
Note: The billing code is one thing with service_id.
If a mobile phone user sends a message, the SP can send the message. The mobile phone assigns a linkid based on an uplink. within a certain period of time, the SP can send the message to the mobile phone user and send multiple messages, however, each piece of information is the same linkid.

, A linkid can carry a billing code (this is reported on the mobile phone, with this code, the fee is deducted, 1 yuan, 2 yuan or N yuan)
For example, if mobile phone 13912345678 sends an upstream message "A", the command is reported by the mobile phone. If the MISC platform uses this command, a linkid is allocated and returned to the SP, SP determines what services the user uses based on command a, and then

Send a message. Send the message with lingkid and billing code. Otherwise, the message cannot be issued. For example, send 3 messages, the linkid and billing code of each message are the same (because the user only has one upstream command), even though SP sends 3

Only one item can be deducted. The linkid and billing code are only used to ensure the successful delivery of information. All businesses are like this, on-demand videos, and customization later

2. customized business:
Its service_id is preceded by a-number, for example,-ylqtyx
A mobile phone user sends a message once. After MISC authentication, the User acknowledges that he is willing to use the customized service and lists him as a Custom User. After that, even if the user has not sent any information, the SP can also send messages to him, but no messages are assigned at this time.

The linkid is only service_id, which is the billing code. This service_id must be included in each message.
 
He also has two sub-categories.
1) Customized by bar
SP can send messages to users with order relationships. Each time a user receives a message, the user will be charged according to the charges indicated by service_id. For a month, the user will be deducted 10 yuan at most, and the fee will exceed 10 yuan, it still needs to be delivered with service_id,

No fee is deducted for mobile devices (SP is not required for this part)
2) monthly subscription business
SP can send information to users with order relationships. All information must be delivered with service_id, and the deduction is initiated by mobile devices, regardless of SP.

Iii. Development Technology
As long as the first protocol and specification requirements are met, the current popular development languages and databases can be used.
1. The key is network programming and soap programming.
2. Glossary
Misc (Mobile Information Service Center) is a data operation platform that fully complies with the technical specifications of China Mobile Data Service Management Platform (dsmp). It manages and controls data services.

Can implement user management, business management, and SP management, provide open, standard, and unified web service interfaces, and provide billing for each service gateway and sp.

The smpp interface protocol was originally included in the gsm03.39 specification by ETSI. It describes the Protocol relationship and data transmission format between the short message center and the short message entity. This specification describes the smpp interface protocol.

For simple communication, the Protocol version number is set to v3.30 by standardized manufacturers. Then, the smpp Developer Forum will change the Protocol version to v3.40, And the smpp v3.40 protocol specification is fully compatible with G.

SM 03.39 protocol standard. In this specification, the interface between the short message center device and the short message stock trading business processing platform adopted adopts the gsm03.39 v3.30 protocol specification. Unless otherwise stated

The proposed specifications shall prevail. The smpp protocol can use TCP/IP or X.25 as the underlying communication bearer.

Ismg intenet Short Message Gateway

Dsmp Data Service manage Platform Data Business Management Platform

Smpp Short Message Peer to Peer Short Message Point-to-Point Protocol

CMPP China Mobile Peer to Peer China Mobile Point-to-Point Protocol
The CMPP protocol provides the following two types of business operations:
(1) Short Message mobile originate, SM Mo)
For detailed procedures, see Alibaba Cloud mobile dream text message service signaling process specification v3.0.0.
(2) Short Message mobile terminated, SM Mt)
For detailed procedures, see Alibaba Cloud mobile dream text message service signaling process specification v3.0.0.

SMSC Short Message Service Center Short Message Center

GNS gateway Name Server Gateway name server (GATEWAY)

SP service provider

Ismg_id gateway code: 0xyz01 ~ 0xyz99, where XYZ is the provincial capital code. When the number of digits is insufficient, the left is filled with zero. For example, the gateway code of Beijing 1 is 001001, And the gateway code of Jiangxi 1 is 079101.

Enterprise code of sp_id SP: The SP address and identity in the network, address translation, billing, and settlement are all based on the enterprise code. The enterprise code is represented by a number. There are 6 digits in total, from "9xy000" to "9xy999", where"

XY "is the code of various mobile companies

Service Code of sp_code SP: the service code is the service provider code that is provided to users in upstream businesses using SMS. The service code is represented by a number. The length of the National Service Code is 4 bits, that is, "1000

"-" 9999 "; the length of the local service code is five characters in length, that is," 01000 "-" 09999 "; the Ministry of Information Industry has put forward new requirements for the service code distribution of the new SP, the prefix must be "1061"-"1069". Currently, China Mobile

An animation is allocated as follows:
1062: used for SP service code in the province
1066: used for SP Service Code nationwide
Other segments are retained.

The service type, combination of numbers, letters, and symbols of service_id sp, Which is customized by sp. The piece transmission condition can be set to tpcq, and the stock query can be defined as 11.

Dsmp data Business Management Platform
SSO Single Sign on
HTTP Hyper Text Transfer Protocol: hypertext transfer protocol.
HTTPS Hyper Text Transfer Protocol over Secure Socket Layer, Hypertext Transfer Protocol Based on Secure Socket Layer.
ICP Internet content provider, Internet content provider
WWW World Wide Web
XML eXtensible Markup Language, eXtensible Markup Language
Session refers to a complete session process in the HTTP access process.
 
The Internet Short Message Gateway (ismg) is an intermediary entity between the service provider (SP) and the SMS center in the mobile network. On the one hand, the Internet Short Message Gateway is responsible for receiving information sent from the SP to the mobile user and submitting it to the SMS center. On the other hand, mobile

The user's On-Demand SP business information will be sent to the SP by the SMS center through the Internet SMS gateway. In addition, in order to reduce the signaling load of the SMS center, the Internet SMS gateway should also forward the SP submitted information to the corresponding Internet short messages according to the routing principle.

Email Gateway. The Internet SMS gateway obtains the forwarding route information between gateways by querying the gateway (GNS.
In addition, ismg must be connected to the Data Service Management Platform dsmp to authenticate users, businesses, and order relationships in the business process and approve the business.

3. Interface naming rules
The interface name is in the upper case of the first letter and the lower case of other letters. Uppercase letters in abbreviations; interface parameters and messages
In terms of capacity definition, the naming rules for fields of the basic data type are in the form of uppercase letters and no connectors between words.
Keywords, such as ID, URL, ICP, and msisdn, are all capitalized.

The SSO platform is actually part of the user's local dsmp function. During login, the user must be redirected to the user's self-service portal of dsmp in the same region. No matter whether the whole network SP or the local sp, the user is logged on to the SSO platform in the same region as the user.

And complete session management. The information subscribed by the user is stored on the local dsmp platform, and the user authentication is completed by the local dsmp. Therefore, the SP must be connected to the SSO platform of the access location to complete session management.

At the same time, there is also a need for a mechanism between each SSO platform to manage and synchronize the user data required for each other, to ensure that user data can be obtained on any SSO platform. To meet this requirement, we recommend that you use centralized control and

The implementation requires synchronization, that is, there is a unified central node in the entire dsmp deployment architecture, which stores all logged-on user data in a centralized manner, provincial SSO platforms redirect users to central SSO when users need to log on.

To complete the login operation. For specific procedures, see user logon, business subscription/VOD, and user logout procedures in the following sections.

Iv. Data Description

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> the Message ID
</SOAP-ENV: Header>
SOAP-ENV: Body>
<Syncorderrelationreq xmlns = "http://www.monternet.com/dsmp/schemas/">
<Version> 1.5.0 </version> indicates the version of the interface message.
<Msgtype> syncorderrelationreq </msgtype> Message Type
<Send_address> the sender's address
<Devicetype> 0 </devicetype> device type 0: dsmp
<DeviceID> 0011 </DeviceID> device ID
</Send_address>
<Dest_address> the recipient's address uses the user ID. When the user and the billing user are the same, the feeuser_id and destuser_id values are the same.
<Devicetype> 400 </devicetype> device type 400: SP
<DeviceID> 0 </DeviceID> device ID
</Dest_address>
<Feeuser_id> billing user ID
<Useridtype> 1 </useridtype> User ID type 1: mobile phone number
<Msisdn> 13912345678 </msisdn> mobile phone number
<Pseudo code> </pseudo code> User pseudo code
</Feeuser_id>
<Destuser_id> User ID
<Useridtype> 1 </useridtype> User ID type 1: mobile phone number
<Msisdn> 13912345678 </msisdn> mobile phone number
<Pseudo code> </pseudo code> User pseudo code
</Destuser_id>
<Linkid> sp </linkid> transaction ID of the temporary subscription relationship
<Actionid> 2 </actionid> service status management action code. The specific values are as follows: 1: Service Activation; 2: service suspension; 3: Service Activation; 4: service suspension;
<Actionreasonid> 1 </actionreasonid>

Actionreasonid: the code that generates the service status management action. The specific value is as follows: 1. The code that generates the service status management action reason when a user initiates the action. The specific value is as follows:
1. User-initiated Behavior
2: Admin & 1860 initiated
3: Boss Shutdown
4: Start boss
5: Transfer boss ownership
6: Boss sales
7: Change the boss number
8: Service canceled due to deduction failure
9: Others

<Spid> 419613 </spid> SP enterprise code
The service code of the Service in <spserviceid>-ltylby </spserviceid> sp, indicating the content of each service, also known as the billing code.
<Accessmode> 3 </accessmode> service access method 3: SMS 2: WAP 1: Web
<Featurestr> mta2njixndqgverbra ==</featurestr> the service order parameters are base64-encoded.
</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> Message ID
</SOAP-ENV: Header>
SOAP-ENV: Body>
<Dsmp: syncorderrelationresp xmlns: dsmp = "http://www.monternet.com/dsmp/schemas/">
<Msgtype> syncorderrelationresp </msgtype>
<Version> <% = version %> </version> indicates the version number of the interface message. The versions of all interface messages are "1.5.0
<HRET> <% = HRET %> </HRET>
</Dsmp: syncorderrelationresp>
SOAP-ENV: Body>
SOAP-ENV: envelope>

3. Cancel the service request package
Reverse cancellation process description:
Reverse cancellation is a cancellation process initiated from the sp. When the MISC processes a cancellation message from the SP, the process is the same as that of a message from other network elements. The process is as follows:
(0) SP initiates a reverse cancel request unsubscribeservicereq to MISC and waits for MISC to process the request;
(0) MISC authenticates the source address and enterprise code in the message to determine whether to allow reverse cancellation of the SP;
(0) after successful access authentication, perform user authentication and order relationship authentication to determine whether the user's status is correct and whether there is a subscription relationship;
(0) after the authentication is successful, MISC sends the subscription relationship synchronization request packet syncorderrelationreq to the sp;
(0) After receiving the synchronization request, SP cancels the order request and returns the Synchronous Response syncorderrelationresp to the order relationship;
(0) After receiving the response, MISC checks whether the response value is 0. If the response value is 0, the order relationship is canceled in MISC, and a successful reverse cancellation response packet unsubscribeserviceresp is returned to the sp. If the response value is not 0

Unsubscribeserviceresp;
(0) if the SP receives an error response from MISC, the cancellation fails. The SP must handle the failure message, such as restoring the canceled order relationship;
(0) if the system receives the correct response from MISC, the SP can not process it;

<? 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> the Message ID
</SOAP-ENV: Header>
SOAP-ENV: Body>
<Unsubscribeservicereq xmlns = "http://www.monternet.com/dsmp/schemas/">
<Version> 1.5.0 </version>
<Msgtype> unsubscribeservicereq </msgtype> Message Type
<Send_address> the sender's address
<Devicetype> 400 </devicetype>
<DeviceID> 913002 </DeviceID>
</Send_address>
<Dest_address> receiver address
<Devicetype> 0 </devicetype>
<DeviceID> 0024 </DeviceID>
</Dest_address>
<Feeuser_id> billing user ID
<Useridtype> 1 </useridtype> see the following definition.
<Msisdn> 13805002424 </msisdn> mobile phone number
<Pseudo code/>
</Feeuser_id>
<Destuser_id> when the user and the billing user are the same, the feeuser_id and destuser_id values are the same.
<Useridtype> 1 </useridtype>
<Msisdn> 13805002424 </msisdn>
<Pseudo code/>
</Destuser_id>
<Service_id> service ID
<Serviceidtype> 1 </serviceidtype>
<Spid> 913002 </spid>
<Spserviceid>-tqaau </spserviceid>
<Accessno/>
<Featurestr/>

</Service_id>
<Featurestr/>
</Unsubscribeservicereq>
SOAP-ENV: Body>
SOAP-ENV: envelope>

Cancel service response package
<? 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> return value: See the following definition.
</Unsubscribeserviceresp>
SOAP-ENV: Body>
SOAP-ENV: envelope>

4. Return Value Definition

For the status code during HTTP Communication, see the status code value specified in HTTP/1.1, not included in this
Standardized return values are uniformly defined.
The detailed description is as follows:
0: Successful
1: Unknown error
2-99: Reserved
4000-4999 indicates the error code in the interface message between MISC and SP:
4000: The msgtype is invalid.
4001: The action_id is invalid;
4002: The action_reasonid is invalid;
4003: Invalid SP ID
4004: Invalid serviceid
4005: Invalid pseudo code
4006: The accessmode is invalid.
4007: The MISC service is activated synchronously, but the SP end already has a subscription relationship and the status is activated.
4008: MISC synchronously activates the service, and the SP end does not have a subscription relationship, but the service fails to be activated.
4009: MISC activated the service synchronously, but the SP end already has a subscription relationship and the status is paused.
4010: MISC synchronously stops the service and the SP end has a subscription relationship, but the service fails to be canceled.
4011: MISC stops services synchronously, but the SP end does not have a subscription relationship
4012: MISC synchronously suspends the service, and the SP end has a subscription relationship, but the service suspension fails.
4013: the service is suspended by MISC, but the SP end does not have a subscription relationship.
4014: The MISC service is suspended synchronously, but the SP end has a subscription relationship and the status is paused.
4015: MISC synchronous activation service, but the SP end already has a subscription relationship and the status is activated
4016: MISC synchronously activates the service, but the SP end does not have a subscription relationship
4017: MISC synchronously activates the service, and the SP end has a subscription relationship, but the activation fails.
9000-9999 is a system-level error:
9000: system disk read/write error
9001: network exception
9002: a network error occurs.
9003: the service gateway is busy and the Service Gateway caches
9004: the service gateway is busy, the Service Gateway buffer is full, and MISC is cached. Do not send messages temporarily,
Wait for a while and try again.
9005: MISC busy, MISC Cache
9006: MISC is busy, the MISC buffer is full, and the Service Gateway caches the message. Do not send messages temporarily. Wait for a while and try again.
9007: the traffic of the Service Gateway exceeds the limit.
9008: MISC exception, not available
9009: Service Gateway exception, unavailable
9010: the service gateway does not have the permission to call the interface message.
9011: MISC has no permission to send the interface message to the service gateway.
9012: Unsupported version
Page 1
Misc SP Business reverse Interface
9013: incorrect message type, not supported by the system
9014: verification error. Unable to parse the soap and XML structures, missing required fields, or messages. Incorrect format
9015: the server cannot complete the requested service because the message is rejected.

5. devicetype Definition
Device Type
0: dsmp
100: ismg
101: wap sp proxy
1xx: Other service gateways
200: WAP Portal
201: www Portal
202: Voice Portal
203: PDA Portal
2XX: other portals

300: mmsc
301: kjava Server
302: LSP
3xx: other application platforms

400: SP

6. DeviceID Definition
Device ID. The device ID uses the inbound ID of each device. For example, the SMS gateway uses the gateway ID and the enterprise code of the SP. The device ID is assigned by dsmp, the ID is unique in the same device type.

7. useridtype Definition
User ID type
1: mobile phone number
2: mark with a pseudo code
3: both are identified

8. sptype
SP business type
1: All sp
2: SP that provides the SMS Service
3: SP that provides the WAP Service
4: SP that provides the MMS Service
5: SP that provides kjava services
6: SP that provides the mail service
7: SP that provides the LBS Service
8: SP that provides WWW Service
9 ~ : Extension

9. serviceidtype
Service type identification method:
1: spid + spserviceid
2: accessno + featurestr

V. Description of MISC's business matching process for mo
Handling instructions:
1. When SP applies for business, fill in the business instructions according to different business types, there may be four command modes: "Order command", "cancel command", "On-Demand command", and "normal Mo ".

Determine the sending number (long number) and instruction content corresponding to the instruction, and specify whether exact match is required for the sending number and instruction content.
Exact match means that a match is performed only when the matched content and the configured Command need to be identical (including the same length. For example, if the sending number is set to "800101", only when the user sends a message

"80010123" will not match the command with "800101"; only the command sent to "800101" will be matched.
[Note] for the same command mode, multiple commands can be set for each service. For example, five order commands and five cancellation commands can be set for a service, currently, MISC supports more than five commands.

One mode command. We recommend that you set no more than five SP commands.
2. the user's MO text message consists of two parts: the sending number and the content to be sent, plus the matching mode set during the business application. These three forms constitute the basis for matching.
3. When a mo to MISC is authenticated, MISC first matches the sending number (long number) based on the maximum matching + precise matching principle. If a match is successful, the corresponding business code and command type are taken out.

If not, authentication fails and the mo cannot be sent to the SP.
4. In the list matched in the previous step, the command content is matched based on the maximum matching + exact matching principle. If there are matching results, the corresponding business code and command type are taken out; if there is no matching result

Then, the system returns a null value based on the service ID and notifies the SMS gateway to forward the message to the SP as a normal Mo.
5. SP should try to avoid nested commands when entering the mo order command (for example, "888801" and "8888011" accessno at the same time ).
6. For successfully matched commands, MISC processes the commands in the following mode:
? For the order command, MISC will check whether the user has subscribed to the service. If no order is made, MISC will complete the order, at the same time, the user's Mo content will be synchronized through the user's subscription relationship data synchronization interface (Provision Interface)

In the featurestr field of the provision interface, the long number and command content of the user Mo will be sent to the SP. The long number and command content will be separated by a space character. At the same time, MISC will notify the SMS gateway that this is an order command, short

The email gateway does not forward the MO to the SP.
If the user has subscribed to the Service, for the monthly subscription service, MISC will regard the MO as a normal Mo and return the result of successful authentication to the SMS gateway, notify the SMS gateway to forward this text message to the SP as a normal Mo. for customized monthly subscription services,

Then MISC will regard the MO as the on-demand Mo and return the authentication success result to the SMS gateway, notifying the SMS gateway to forward the message to the SP as the on-demand Mo.
? For the cancellation command, MISC will check whether the user has subscribed to the service. If the user has subscribed to the service, MISC will complete the cancellation, at the same time, the user's Mo content will be synchronized through the user's subscription relationship data synchronization interface (Provision Interface)

In the featurestr field of the provision interface, the long number and command content of the user Mo will be sent to the SP. The long number and command content will be separated by a space character.
If the user does not subscribe to the service, MISC will return an authentication failure to the SMS gateway, and the SMS gateway will not forward the MO to the SP.
? For VOD instructions, MISC must first determine whether the service is customized or common
1) for customized broadcasting businesses, You need to determine whether the user has subscribed to the service. If the service has been ordered, MISC will generate a temporary subscription relationship (linkid) and return the authentication success message to the SMS gateway, and return the linkid to the SMS.

The SMS gateway forwards the MO to the SP as the on-demand Mo. If the user does not subscribe to the MO, MISC simply returns a successful authentication response to the SMS gateway, the notification SMS gateway forwards the message to the SP as a normal Mo.
2) for the broadcasting business, MISC will generate a temporary subscription relationship (linkid) directly, return authentication success to the SMS gateway, and return the linkid to the SMS gateway, the SMS gateway forwards the MO to the SP as the on-demand Mo.
? For normal Mo messages, MISC returns a successful authentication response to the SMS gateway, notifying the SMS gateway to forward the message to the SP as a normal Mo.
Example description:
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)
[Note] accessno indicates the mo sending number.
Featurestr indicates the instruction content
Ancheckflag indicates whether to use exact match for accessno
Fscheckflag indicates whether to use exact match for the command content

For the above settings,
The user sends xw1 to 8888011. We match 3rd records.
The user sends xw01 to 888801 and we will match 2nd records (the longest match access number first)
The user sends 888802 x 5th to 4th. We matched 4th records (records are not matched, because the accessno of the records is an exact match)
The user sends 8888 x 4th to. We matched records.
The user sends xw01 to 8888. We match 1st records.
The user sends a to 8888 and we match 5th records,

Vi. Business instructions

Business category business name IOD push STK product description
Business Code on-demand instruction billing Type Price Return items Business Code billing Type Price sending frequency Business Code

Number of price items returned for the billing type
Application Service harny hy sends a natural statement to XXX monthly subscription of 5 RMB 1 through natural language and virtual master

Communicate with "haeni"
Chat handsome brother and sister lt send a to XXX according to the article 0.2 yuan 1 user registration allocated ID number, pass

Chat with anonymous friends by ID
Test actually does not understand your heart CS send P to XXX monthly 7 yuan 1 psychological test Daquan
Game fengyue qiaojia's JR fa m to XXX monthly 7 yuan 1 love role game
The game is very confessed to the GB method GB to XXX by 0.2 yuan 1, emotional stories
Test identification of male and female NV method NV to XXX by 0.2 yuan 1 love test game
The swordsfish and water story ys method to XXX according to the article 0.1 yuan 1, 2
Test guoyun caiyun taohuayun yufa Yu to XXX by 0.2 yuan 1 birthday Test
Game daughter country YG method YG to XXX by 0.2 yuan 1 yuan Travel role game
The game goes to the left to the right to get ZY to XXX, and press the 0.2 yuan, cartoon text message story
The game sweetheart XR method XR to XXX by 0.3 yuan 1 through the other party's message, guess his mobile phone number
Test star Zhixin XX method XX to XXX by 0.2 yuan 1, 3 constellation Test
Yi Cheng tarot brand TL method TL to XXX monthly package 7.0 yuan 1, 3 tarot brand text message version
Yi Cheng name and life XM method XM to XXX by 0.4 yuan 1, 4 name Test
In the past and present, the QS method from the game to the xxx method is 0.5 yuan, birthday games.

-- That is, as long as a packet starting with a letter is sent to the start of the corresponding port, mobile considers that there is a VoD or custom relationship. What is the difference between services and the packages received by provision, currently, this is basically done.
-- Because mobile has no free code, that is, the original Free Code cannot be used, there is no error message. If you have already designed it, the fee is deducted;
-- As long as the user has a subscription relationship, all downstream users must use the billing code downstream, and the Custom Service will be charged. The monthly subscription service will be issued with the billing code, so mobile will not regard it as a silent user

VII. dsmp platform Web Services Interface Definition and soap binding
Dsmp platform Web service interface design and development principles
All Web service interfaces in the dsmp specification are based on Web Services issued by W3C
Description
Language (WSDL) 1.1 (2001/03/15) specification, designed and defined, and later versions with the WSDL Standard
Related provisions in
To maintain consistency. The design and development of interfaces for all products adopting the dsmp specifications shall comply with the following principles:
The XML schema definition for all messages and related data types in the interface should be provided by this specification
XML
Mode definition. For details, see appendix C. When deploying a web service, all the XML modes defined by dsmp
Definitions are included in the dsmp. XSD file and referenced with a public URL. In the WSDL Definition
Use the namespace named dsmp as the limit. In the definition of WSDL
Xmlns: dsmp = "http://www.monternet.com/dsmp/dsmp.xsd”. dsmp:
Prefix, for example
For example:
<Message name = "SG. userregisterreq">
<Part name = "userregisterinput" type = "dsmp: userregisterreqtype"/>
</Message>
The Appendix defines the namespace and XML schema of all referenced types and elements for the dsmp specification.
Empty name
The interaction scope covers all WSDL interface messages. For how to use namespaces in soap messages, see section 2nd.
Example:
Page v
Ming.
The WSDL definition of interfaces should adopt the WSDL definition provided in this specification. For details, see section 3rd of this appendix.
When you deploy a web service, all the WSDL definition content is included in the dsmp. WSDL file, and
The public URL is referenced. According to the WSDL standard, the WSDL definition of this standard interface mainly includes
As follows:
Type (types): This specification uses the file reference method, all messages defined by the dsmp Specification
Type is included in the dsmp. XSD file;
Message: refers to the message in the soap encapsulation of the request or response generated during the call process.
Structure;
Operation: A Theoretical description of the actions supported by the web service defined in this specification;
Port type: defines the set of operations supported by the terminal;
Binding: The definition part of the soap binding. According to the wsdl1.1 standard, the port type
Is bound to the soap1.1 protocol. Therefore, any product that adopts the dsmp specification, no matter what
Supports the Web Service middleware platform or soap special program to implement the Web service interface,
Or you can call the Web service interface to bind soap1.1. For example
The message package can be returned correctly only when a standard soap encapsulated message package is sent to the server. No
The call format is invalid;
Port: defines the network address of the program implementing the interface;
Service: A series of port sets that implement interfaces.
Soap binding principles
The Web Service Interface defined in this specification is bound to the soap1.1 protocol format, and all requests and responses are eliminated.
Message encapsulation in the soap format, including the SOAP envelope and the SOAP Header
(Header)
And the soap package body. For callers of any technical implementation, call requests are sent out
Message average
It must contain the preceding three parts. The types referenced in the header and package body message structures are from
Definition.
However, in the soap package, if a parameter is defined as optional according to the specification, the SOAP message does not contain
Identifier
The element of this parameter. The structure of the returned SOAP message is the same as that of the request message;
In this specification, the transactionid parameter defined to support transaction processing is included in the SOAP Header
Medium
Therefore, all soap messages must contain a SOAP header.
The transactionid in the soap header needs to be processed (used to identify a thing or ignore it ).
The rule for generating transactionid is DeviceID + 10 digits, which start from 1,
And the first digit of less than 10 digits is 0. The step size for each increase is 1, which is used cyclically.
This specification complies with the WSDL standard. The interface communication layer is bound with post and get of http1.1 protocol.
According to the provisions of this specification, both the server and the client interact through the http post method. And
Related: The content format of the HTTP message is bound to the MIME format. For example, the Content-Type is text/XML.
All follow the MIME standard
The above is a summary of the key content obtained from the development experience of SMS, because it was just a few months ago, there are a lot of details not included, detailed content can view the relevant documents. In addition, there must be many misunderstandings. You can go to my blog to communicate with me.

. You are welcome to reprint it, but the source is indicated. Blog.csdn.net/cutemose