I am using EASYSMPP to send SMSes through an SMPP server, however am unable to capture the exact responses from the SMSC because the function client.SendSMS, returns either TRUE(for sent SMS) or FALSE(for a failed SMS). I want to be able to log those responses so that I can share with the service provider for analysis.
Kindly assist.
Related
I am using RabbitMq with masstransit for messaging between different services, let us say that we have the following scenario:
First service asks about specific info from second service by sending a request.
Second service looks for the info in database and respond with an object containing the found info.
In case there is no info available in database, the second service responds with a null object.
The issue is that RabbitMQ is considering that the request has failed thus it keeps sending the request again.
Can I configure the bus to consider the null reponse as a normal response?
You cannot reply with null object. You have two options:
Add a boolean property to your response indicating it is not a success
Throwing an exception in the request consumer, then the fault message will be sent to the request client.
Suppose that case when the client app has re-registered with the gcm itself but the server is unaware of this and now the server is sending notification to that particular client what I want is the notification should not be sent with the old registration id. How can this be done?
If your server sends a message to an invalid Registration token, it will probably receive a NotRegistered error response. You should handle this error accordingly by removing the corresponding token. As per the documentaion I linked above:
For all these cases, remove this registration token from the app server and stop using it to send messages.
I am working on a chat app using XMPP Protocol.
I tried following
this tutorial from github . Everything is working fine using
XMPP.
But I'm unable to receive offline messages when user comes
online.
As user A is logged out and user B sends messages to user A, and when user A logs into app, it must receive all the messages that
were sent by user B during offline session.
How can I receive these offline messages?
My app is totally stuck on this issue. Please help if anyone
knows the solution. Any help will be appreciated. Thanks
You need to enable mod_offline on server, if you are using ejabberd XMPP Server.
Here is the code needs to enable module:
ignore_pep_from_offline: true
max_user_offline_messages:
admin: 5000
all: 100
mod_offline:
access_max_user_messages: max_user_offline_messages
Write this code in ejabberd.yml config file.
It will store unto 100 messages per user received when client was offline.
At client side, you may have to register for service:
'http://jabber.org/protocol/disco#info'
If you done this, whenever offline client gets online, server will send those stored messages to respective client.
You've to send Request for offline message if server supports. XMPP works on TCP protocol so as soon as client is up, it should send request to server.
<iq type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/offline'/>
</iq>
Whenever I try to call Magento's rest resources via PHP, I get an HTTP 500 Internal Server Error. My link is, in accordance to Magento's REST API, http://mymagento.com/api/rest/products.
Everything is set up properly and whenever I try to access it via the browser, the response is a page with the XML data I want. Same thing goes for the RESTClient plugin for Firefox.
I also get the internal server error whenever I try to do an authorised request as a customer.
Does anyone know why this is happening? I ran out of ideas an hour ago or so.
If you just got that problem (only) then,
500 errors in the HTTP cycle
Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:
Obtain an IP address from the IP name of the site (the site URL
without the leading 'http://'). This lookup (conversion of IP name to
IP address) is provided by domain name servers (DNSs).
Open an IP socket connection to that IP address.
Write an HTTP data stream through that socket.
Receive an HTTP data stream back from the Web server in response.
This data stream contains status codes whose values are determined by
the HTTP protocol. Parse this data stream for status codes and other
useful information.
This error occurs in the final step above when the client receives an HTTP status code that it recognises as '500'. (Last updated: March 2012).
Fixing 500 errors - general
This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyse the logs which should give further information about the error.
Can someone please explaind me what is DLR and how it used in sms gateways?
It is a URL callback for Delivery Reports. Instead of the gateway logging the activity it will callback the provided URL using a querystring at the end with the parameters of the delivery report.
So in order for the URL callback to work you'll need a HTTP webserver with a URL that listens for incoming GET requests:
http://www.example.com/dlr.php
then requests are sent to it like so
"http://example.com/dlr.php?page=dlr&status=[status]&answer=[answer]&to=[to]&ts=[ts]&id=[id]"
The full listing of documentation can be found here.
When you send messages through a gateway you have the opportunity to specify wether or not you want to be notified of events other than the SMSC receiving your message.
When you do specify that you want to receive DLRs the gateway will send you a DLR to let you know that the result of attempting to deliver the message to the network. In case of failure the DLR will contain a code about the reason of failure.
Gateways may send more DLRs (Intermediate Notifications) to notify of other events that happen after the message has been delivered to the network, e.g., delivery to a handset.
You can find more by looking at the SMPP spec, below is a basic diagram of the flow for a Network Delivery Receipt (taken from the spec v3.4).