I am working with restcom SMSC. I am able establish connection with an ESME node. Restcomm SMSC is acting as smpp server in the connection. Currently, I can receive the message from ESME node. I want to send a message to ESME node. How can this be achieved? What parameter needs to be passed in destination address of message?
Related
I have a sample message flow where a TCP Output Node communicates to an external system and receives response to a TCP Client receive node. My issue is, is there a way whether I can ensure that the TCP request and TCP response are correctly mapped and processed. We have observed in certain circumstances few request and responses getting mismatched. I understand there is a $LocalEnvironment/Destination/TCPIP/Output/Id property in the TCP IP Client Output Node and $LocalEnvironment/TCPIP/Receive/Id in the TCP IP Client receive Node. Should these be same for a single request and response? Should I write an ESQL check to ensure the request and response are correlated? Any advice would be very much helpful.
I successfully installed JasminSMS on Ubuntu, added SMS provider informations such as hostname, port, user and password, but failed to receive test SMS using HTTP API:
http://127.0.0.1:1401/send?username=foo&password=bar&to=*********&content=hello
I'm writing my own number, but I don't receive it. What other configuration do I need to do?
In this scenario (you want to terminate an SMS message by using Jasmin's HTTP API) you need:
Jasmin SMS Gateway installed
An HTTP user configured in Jasmin SMS (this can be done in the included CLI)
An SMPP connector configured in Jasmin SMS to connect to an SMS service provider. The credentials will be supplied by your SMS vendor of choice.
A routing rule in Jasmin SMS Gateway to decide which SMPP connector to use
This is all well-documented here https://docs.jasminsms.com/en/latest/installation/index.html#sending-your-first-sms
If your HTTP API call is successful you'll receive an HTTP success code (200) and a GUID. Jasmin SMS then tries to deliver the SMS message via the SMPP connector (according to the routing rule configured). If your SMS message was not received you need to look into the used SMPP-connector to troubleshoot further. If the message has been accepted by the SMPP connector of choice you'll have to contact your SMPP vendor and ask them to look into the possible delivery issues.
An SMS vendor is basically a company with agreements to various operators & aggregators around the world specializing in delivering SMS messages globally (or locally of course depending on their focus) for a price.
make sure u enter the smsc creditntials on the smpp connector and mae sure it is started(smppccm -1 cid) and check its sessision if it is bound smppccm -l
I am using Artemis 2.6.2 with STOMP only and the following constellation:
Broker:
No queues configured in broker.xml, everything is auto created.
Server:
SUBSCRIBE to destination TaskResponse without selector/filter
SEND to destination TaskRequest with header clientId = ID (the ID of the client what the server would request to)
Client 123:
SUBSCRIBE to destination TaskRequest with selector clientId = 123
SEND to destination TaskResponse with header clientId = 123
When I watch at the Artemis Console the following happens:
No server and no client is connected: No address or queue is present
Server connect: Artemis creates a multicast address TaskResponse and a multicast queue for this address with empty filter
Client 123 connect: Artemis creates a multicast address TaskRequest and a multicast queue for this address with filter clientId = 123
Message exchange: Messages are transfered from server to client and back to server as expected.
Client 123 disconnect: Artemis removes the multicast address TaskRequest and the coresponding multicast queue with filter clientId = 123
Server sends message to TaskRequest for client 123: According to STOMP client on server the message is sent successful. On the broker the message disappears.
Same behavior vice versa: Client 123 is connected and server is not: According to STOMP client on client 123 the message is sent successful. On the broker the message disappears.
My guess is that the message is discarded because there is no route to a subscriber. If I enable the option "send-to-dla-on-no-route" in address-settings section of broker.xml the message goes directly to dead letter queue.
Do you know a way to preserve the messages until the subscriber reconnects?
Appendix 1: STOMP Messages
I am using the Stomp.Net Library with SelectorsCore Example but reduced only to selector s1. The workflow is a bit other than what I wrote above.
Unfortunately I did not found an example to enable logging of STOMP messages into a file in Artemis. Therefore I recorded the packets with WireShark, exported as text and uploaded into Gist StompMessages.txt. You can see there the diffrent STOMP messages, e.g. search for CONNECT, SEND, etc.
Solution
The solution was to use the option anycastPrefix=/queue/ in the acceptor element in broker.xml to force the queues to type ANYCAST:
<acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true;anycastPrefix=/queue/</acceptor>
What you are observing is the expected behavior. If you send a message to an address with no queues (or in STOMP terms - a destination with no subscribers) then the message will have nowhere to go and will be discarded. This is normal pub/sub semantics.
If you want to preserve the messages even if no subscriber is present you can either:
Use anycast (i.e. point-to-point) semantics rather than multicast. This is discussed in the Artemis documentation.
Use "durable" STOMP subscribers as discussed in the Artemis documentation. The caveat here is that the subscription will still need to be created before messages are sent and you will also need to make sure you remove the subscription when you are done with it or it may accumulate messages.
Please I'll like to know the difference between SMS and SMPP or at the very least get pointed to a good resource that breaks down this difference in layman terms. I'm currently on a project where the product vendor says the product only supports SMPP for inbound messages so it cannot be integrated to an SMS gateway. I've tried researching the fundamental peculiarities of SMPP that makes the integration with an SMS gateway for inbound messages impossible for this product but my research has yielded nothing material so far.
I'll really appreciate your feedback as the project is basically at an impasse due to the insistence of the vendor on SMPP.
SMPP is the protocol used to send SMS. Currently there are 2 ways to send a SMS. Either by SMPP (beneath the TCP protocol) or by SS7 (which requires hardware and is costly).
Usually SMS gateways are SMPP which is weird that you are not able to integrate it with it.
In brief, the SMPP protocol does the below:
Client binds to the server (Bind Request) / Server Accept or Reject
bind (Bind Response)
Client Sends SMS (Submit-SM) / Server accepts or Rejects SMS (Submit
Resp) server also includes the message Id
Server sends the DLR with the same message Id in the submit
response(Deliver-SM) / Client acknowledge the DLR (Deliver Resp)
Theres also an Enquire Link sent from the client and its response from the server to keep the connection from timing out usually 30 seconds.
Here's a link describing the SMPP Protocol in details:
http://opensmpp.org/specs/smppv34_gsmumts_ig_v10.pdf
I send SUBMIT_SM command with all required data and successfully get SMS to my mobile phone.
I see on my SMPP server log that DELIVER_SM_RESP is received from SMSC but I can't see logic how to request from my api (that i'm building) to get this DLR.
Do I run:
DELIVER_SM = 0x00000005
or
QUERY_SM = 0x00000003
I tried with both but for DELIVER_SM got error, and can't see nothing in QUERY_SM.
Please advise, thanks in advance.
Vedran
A delivery receipt will be sent back to your SMPP server via a DELIVER_SM message if you have the registered_delivery field set correctly in your message (make sure). Are you using Kannel or some other SMPP server or did you write your own?
Your SMPP stack software is the one responsible of handling any received DELIVER_SM containing valid message-receipt-acknowledgement content and pushing it to your API through SMPP, HTTP or whatever enabled protocol, what's your SMPP stack ?