How to check for the delivery report of the sent message. I am using PHP and I have the SMPP account. Can somebody help me with the checking of delivery report?
Will I get a delivery report as message like we get in our mobile?
Or the status of the send function will do for it?
Using SMPP you can retrieve delivery report in the following ways.
First choice is to set registered_delivery parameter to 1 when you send submit_sm PDU.
In this case SMSC should send you deliver_sm PDU with esm_class = 0x04 containing delivery report.
Other way is to request delivery status with query_sm command but this may generate more traffic if polling SMSC too often.
If you're asking about the format in which the Delivery_Receipt will be delivered back to the source then it's carried as the user data payload in the SMPP deliver_sm or data_sm operation.
The following fields are relevant in the deliver_sm and data_sm operations when used for transmitting delivery receipts:
• source address (i.e. source_addr_ton, source_addr_npi, source_addr)
• destination address (i.e. dest_addr_ton, dest_addr_npi, destination_addr)
• esm_class
• message_state
• network_error_code
• receipted_message_id
SMS delivery receipts are regular SMS text messages generated by SMSC, but esm_class = 0x04 is used to differentiate them. The esm_class = 0x04 means PDU direction is SMSC > ESME and short message contains SMSC delivery receipt short message.
Short message area of deliver_sm SMPP PDU consists below text format which is encoded using dcs=0x00 data coding scheme (i.e. SMSC Default Alphabet according to the SMPP specification):
id:{message_id}
sub:{message_sub}
dlvrd:{message_dlvrd}
submit date:{message_submit_date} done
date:{message_done_date}
stat:{message_stat}
err:{message_err}
Sample delivery receipt message text:
id:40072910491427628 sub:001 dlvrd:001 submit date:1007291049 done date:1007291049 stat:DELIVRD err:000
Adding the following link here for details of processing the sample message above:
SMS Delivery Reports with SMPP protocol
Related
I have a Splunk forwarder which sends events to two third-party systems(through TCP) and also index them into a splunk indexer.
The problem I'm facing on is that if any of the two third-pary systems goes down. Splunk stops indexing events and neither sends them to the other system.
The output.conf I have is:
[tcpout]
defaultGroup = default-system1, default-system2
indexAndForward = 0
[tcpout:default-system1]
server = <IP>:<PORT>
[tcpout-server://<IP>:<PORT>]
[tcpout:default-system2]
server = <IP>:<PORT>
sendCookedData = false
Is there any way to avoid such a dependency? If one of the destinatios servers is down, it doesn't affect the other sending. I've been looking at the documentation and there are some options that could be use.
heartbeatFrequency in combination with sendCookedData.
heartbeatFrequency = <integer>
* How often (in seconds) to send a heartbeat packet to the receiving server.
* This setting is a mechanism for the forwarder to know that the receiver
(indexer) is alive. If the indexer does not send a return packet to the
forwarder, the forwarder declares the receiver unreachable and does not
forward data to it.
* The forwarder only sends heartbeats if the 'sendCookedData' setting
is set to "true".
* Default: 30
sendCookedData = <boolean>
* Whether or not to send processed or unprocessed data to the receiving server.
* If set to "true", events are cooked (have been processed by Splunk software).
* If set to "false", events are raw and untouched prior to sending.
* Set to "false" if you are sending events to a third-party system.
* Default: true
But I'm not sure if it's the most correct approach, based on the description of sendCookedData, "Set to "false" if you are sending events to a third-party system."
Don't send cooked data to third-party systems. That way lies sadness.
Unfortunately, the behavior you describe is normal for Splunk. From all outward appearances, there is a single output queue and all destinations are fed from that one queue. To avoid data loss, all sending stops when one destination is unavailable.
Basically after every IN, OUT or SETUP transaction we have an ACK/NAK packet at the end of the transaction. If a handshake packet is part of every transfer as it comes after the data packet which is preceded by token packet, then why do we need a status stage? This seems to be present in the control transfer.
In the protocol endpoints are in a status: ACTIVE, HALT, STALL,...
in the status phase this status is determined (GET_STATUS(0x00) request (http://www.beyondlogic.org/usbnutshell/usb6.shtml) )
The status phase check is a bit like a CRC checksum over the entire request not over each single packet.
http://www.beyondlogic.org/usbnutshell/usb4.shtml:
"
Status Stage reports the status of the overall request and this once again varies due to direction of transfer. Status reporting is always performed by the function.
IN: If the host sent IN token(s) during the data stage to receive data, then the host must acknowledge the successful recept of this data. This is done by the host sending an OUT token followed by a zero length data packet. The function can now report its status in the handshaking stage. An ACK indicates the function has completed the command is now ready to accept another command. If an error occurred during the processing of this command, then the function will issue a STALL. However if the function is still processing, it returns a NAK indicating to the host to repeat the status stage later.
OUT: If the host sent OUT token(s) during the data stage to transmit data, the function will acknowledge the successful recept of data by sending a zero length packet in response to an IN token. However if an error occurred, it should issue a STALL or if it is still busy processing data, it should issue a NAK asking the host to retry the status phase later.
"
or see http://wiki.osdev.org/Universal_Serial_Bus
"
Finally, a STATUS transaction from the function to the host indicates whether the [control] transfer was successful.
"
I am trying to find any element refer to IncomingBitrate in webrtc dump file .
Where I can find the incoming bitrate in webrtc-internals?
Also, How I can calculate incoming bitrate from webrtc stats?
In webrtc-internals check the active connection -- it's printed in bold. Usually it is Conn-Audio-1-0. There are two fields bytesSent and bytesReceived which will allow you to calculate the bitrate. Also check the constraints + stats demo for an actual example: https://webrtc.github.io/samples/src/content/peerconnection/constraints/
In getStats, iterate the reports until you find one of kind googCandidatePair with .stat('googActiveConnection') === 'true'. That is giving you the same information as webrtc-internals. If you want per-track/stream values, reports of type ssrc have bytesSent or bytesReceived, depending on whether they are sent or received.
Then calculate the bitrate by dividing the bytes sent/received by the time difference between the getStats calls.
I have a snmp enabled device whose monitoring i want to do.
But this device gives response with Request-ID 0 for all the get request. snmp4j library
discards these received packets because it sends get request with some Request-ID value other than 0. On receiving the response it matches the sent "Request-ID" value with the received "Request-ID" value and on finding mismatch it just discards the received packet and returns "null" value to response.
If I set the Request-ID to 0 in snmp packet before sending get request then response snmp packet can be processed.
For this snmp4j library contains the "setRequestID(Integer32 (value))" function to set the desired Request-ID of any snmp packet, but this function cannot set the Request-ID value to 0. When I set the value to 0, this function replaces this value to some random Request-ID value.
If any one having solution then please give response.
Thank you.
The request-id field is used to identify the response when it arrives back to the client. So, if the device you are querying at is returning all requests with a request-id value of 0 instead of the supplied value, then the client (snmp4j) is correctly discarding the response because it is invalid. The request-id in the response packet must always match the request-id in the original request. The device has a buggy SNMP stack. If you change your code to force the requests to always have a request-id of 0 you are breaking functionality to enable compatibility with a non-standard agent and I would advise against it.
I have kannel SMPP (kannel.org) and receive SMS statuses by param: %d
And here is table:
16 = not delivered to smsc
8 = you submitted to smsc. ie smsc tell
kannel he has the msg
4 = msg is in smsc queue. ie smsc tell kannel he queued the msg in its queue.
2 = failed 1 = delivered to phone
But here is very low information. How I can receive more information about (wrong number or something like what)? Now is just failed and whats all, if we want to know why failed we must ask our partners support.
More detailed information on delivery error you can fetch from the following sources:
network_error_code TLV (0x0423) - see p. 5.3.2.31 of SMPP v3.4 specification
text part of DLR message (%A in dlr-url)
command_status in case of rejection (represented as "NACK/$code"
Example of text part in DLR:
id:0832095221 sub:001 dlvrd:000 submit date:1203311115 done date:1204010436 stat:UNDELIV err:011 text:some text here
Here you can see 011 error code in undeliverable message.
However there are many vendor specific issues you need to discover with each new SMSC. And no strict requirements in SMPP specification to information to represented in DLR.
For your DLR URL add this:
dlr_mask=31
dlr_url=....?answer=%A&status=%d
Where DLR bitmask means:
1: Received by phone
2: Failure to deliver to phone
4: Queued for delivery
8: Accepted by other SMSC
16: Rejected by other SMSC
If you get a 16, or your get a 2 it'll look like this:
status=<2 or 16 here>
answer=NACK//
The get a table mapping hex_code to its vendor-specific meaning from the carrier