SMPP连接流量日志解码方法技术咨询

Alright, let’s break down how to decode this SMPP traffic log step by step— I’ve spent plenty of time parsing these logs for messaging systems, so this should click pretty quickly.

First, let's unpack the basic structure of your log before diving into specific details:

• The --> symbol means your system is sending a PDU (Protocol Data Unit) to the remote SMPP peer (labeled bics in your session)
• The <-- symbol means your system is receiving a PDU from the remote peer
• The bics label is just a unique identifier for this specific SMPP connection session

Step 1: Understand the SMPP PDU Header #

Every SMPP PDU starts with a 4-field header, which is what you see in parentheses like (pdu: 0 15 0 1). Here’s what each field means:

• Field 1: command_length (total byte size of the entire PDU, including the header itself)
• Field 2: command_id (numeric code that identifies the PDU type— here are the key matches from your log:
  • 15 = enquire_link (the standard SMPP keep-alive request)
  • 80xxxxxx = enquire_link_resp (response to a keep-alive; the 80 prefix flags this as a response PDU)
  • 4 = submit_sm (the PDU used to send an actual short message)
• Field 3: command_status (a value of 0 means success; non-zero codes map to standard SMPP error codes like invalid address or missing parameters)
• Field 4: sequence_number (unique ID used to match requests to their corresponding responses)

Step 2: Decode Specific PDU Types From Your Log #

Let’s walk through the key traffic entries in your example:

EnquireLink/EnquireLinkResp (Keep-Alive Traffic) #

Your log shows a loop of these PDUs— this is completely normal SMPP heartbeat behavior to keep the connection alive:

• -->(enquirelink: (pdu: 0 15 0 1)): Your system sent an enquire_link keep-alive request (command_id 15), sequence number 1, with no errors (status 0)
• <--(enquirelink_resp: (pdu: 16 80xxxxxx x x)): You received the successful response from the remote peer (note the 80 in the command_id, which marks it as a response)
• The odd one: <--(enquirelink: (pdu: 16 15 x x)): The remote peer sent you a keep-alive request, so your system responded with -->(enquirelink_resp: (pdu: 0 80xxxxxx x x))

Submit_SM (Actual Message Submission) #

This is the most important PDU in your log—it’s where the actual SMS is sent. Let’s break down the entry:

-->(submit: (pdu: 0 4 0 6) (addr: 4 1 64111) (addr: 1 1 320335200002) (sm: enc: SCGSM msg: TextHere) (opt: (short: (tlv: 516) 4) ) )

• (pdu: 0 4 0 6): A submit_sm request (command_id 4), sequence number 6, with a successful status (0)
• (addr: 4 1 64111): The source address of the message:
  • 4 = TON (Type of Number) = International
  • 1 = NPI (Numbering Plan Indicator) = ISDN/E.164 (standard phone number format)
  • 64111 = The source short code or phone number
• (addr: 1 1 320335200002): The destination address:
  • 1 = TON = Unknown (or sometimes national, depending on your SMPP configuration)
  • 1 = NPI = ISDN/E.164
  • 320335200002 = The destination phone number
• (sm: enc: SCGSM msg: TextHere): The message content:
  • enc: SCGSM = Encoding is GSM 03.38 (the standard encoding for SMS messages)
  • msg: TextHere = The actual text of the message
• (opt: (short: (tlv: 516) 4) ): An optional TLV (Tag-Length-Value) parameter:
  • tlv: 516 = Tag ID 516, which maps to source_port (used for SMS over IP scenarios like WAP push)
  • 4 = The value of this parameter (port number 4)

Step 3: Cross-Reference With SMPP Specifications #

For any ambiguous fields (like less common TLV tags or command IDs), you can refer to the official SMPP 3.4 or 5.0 specifications— most core PDUs and parameters are standardized across all SMPP implementations.

内容的提问来源于stack exchange，提问作者loser8