If the ESME sends a PDU to the SMSC will the next response from the SMSC always be the answer to this PDU (let's say "submit_sm_resp" for "submit_sm") or can it be that the SMSC sends me another message like "enquire_link" or "deliver_sm" before sending the "submit_sm_resp"?
Thanks.
It depends mostly on vendor implementation, but SMPP can be either synchronous or asynchronous. Basicaly, if you connect as a transmitter, you will always get response as the first message after you send request. But if you have transceiver bind, you can get request from SMSC before it will send you back response to your submit_sm.
Related
I'm trying to implement SMS transmission between two GSM devices. I've searched and read standards and articles a lot but couldn't find the answer to the following question. Does anyone know how does SMSC get aware of the sender's number and insert it in the TP-OA field of the SMS-Deliver packet stack?
Actually I'm not sure that either this is what you need or this would help you but anyways..
In GSM network there are a lot of nodes and each does certain things for which it is responsible. They communicate to each other with messages, that contain certain information needed for processing of required operation: establishing a call, sending SMS, doing Update Location etc.
So the information about sender's number comes to SMSC from another node called VLR/MSC together with a message saying to it "Yo, one guy wants to send SMS to another guy. So here is this message and information about these guys. Please, forward it".
Here is scenario of user A sending SMS to user B:
User A sends SMS to VLR/MSC together with information about its destination
VLR/MSC then invokes MAP message ForwardSM (Forward Short Message) to send received data further through the network to a node called SMS IMSC
SMS IMSC is a node that plays a role of interface between network and SMSC
SMS IMSC on receipt of ForwardSM message sends TPDU (Transfer Protocol Data Unit) message towards SMSC with the text of sent SMS and routing information
After this SMSC sends reply to user A with a result of receiving the SMS. If it's successful then SMSC starts routing this SMS through the network towards user B
So the message you are looking for is TPDU message from Point 3. Type of this message is SMS-SUBMIT according to TPDU types.
Edit:
Authentication is separate operation that takes place when subscriber starts his activity (eg turns on his phone) or roams to another area that is being served by another VLR/MSC. Anyway, VLR/MSC treats this user as new to this area. Skip this part if you know what is VLR/MSC:
HLR is a node that stores all the information about every subscriber in operator's network. So basically it's a database that has all the info about every single subscriber in the entire operator's network.
And network covers huge geographical area so it's divided is smaller areas called cells. VLR/MSC is a node similar to HLR (it also stores subscribers' data). But it is responsible for one certain cell, so it stores data of subscribers who currently operate in this certain cell. So when new subscriber comes to its area VLR/MSC downloads his data from HLR. And when subscriber leaves this area VLR/MSC removes his data.
And if some node would need to get subscriber's data, it won't "ask" HLR for it, but instead it will "ask" VLR/MSC in whose area the subscriber is currently active.
So when VLR/MSC sees a new subscriber coming to its area, before downloading his data from HLR it triggers authentication process to check if this user is valid and that someone else doesn't pretend to be this user:
VLR/MSC sends Send Authentication Info MAP message together with IMSI (mobile subscriber number which is uniquely identified by his SIM card) to HLR
HLR checks the given IMSI and validates subscriber. If subscriber exists and there is no troubles with him then HLR sends IMSI to AUC (Authentication Center)
On IMSI reception AUC generates a triplet (some encryption keys needed for subscriber identification) that contains SRES, RAND and Kc values and sends this data back to HLR
HLR forwards this data back to VLR/MSC which triggered authentication process
VLR/MSC after reception of SRES, RAND and Kc sends received RAND to mobile subscriber
After mobile subscriber receives the RAND he calculates SRES using given RAND and Ki (some value that is written in user's SIM card) and sends calculated SRES back to VLR/MSC
On the final step VLR/MSC compares SRES generated by AUC with SRES generated by user. And if they match then user is identified successfully, VLR/MSC fetches subscriber's data from HLR and authentication process is completed.
After VLR/MSC downloaded data from HLR every other node that would need data of this subscriber would fetch it from VLR/MSC not HLR. And after that authentication process won't start every time subscriber wants to do something (make a call, send SMS and so on).
So when user A sends SMS to user B the data about user A (his number for example) is stored in VLR/MSC already and it arrives to SMSC from VLR/MSC together with the SMS user A sent.
EMI/UCP is a protocol to communicate to SMS gateways.
I am confused how should I do in respect to network connection.
Do you open a socket for each logic bundle of data (and close it of course), or do you re-use the same socket?
How do you handle out-of-sequence responses in both cases?
My use case is send a couple of SMS with status request (submit short message), each will generate a traffic of 4 messages (a 51 operation and its ack and a 53 operation from the gateway plus the 53 ack).
If I open two sockets, may I be confident each dialog is performed on the some socket or is it a false assumption?
If I use a single socket, how I distinguish the messages from the two conversations? From the OaDC (originator address) only?
Answering the last question: you have to match the time stamp in the Ucp51 response message (ACK). It is the field: SCTS.
The correlation id is the couple SCTS and ADC (address caller: it is the recipient cell phone).
Kannel doesn't seem to be buffering / concatenating inbound multipart messages.
So if I send a message from my cell phone that is longer than 160 chars (2 messages long) Kannel receives the first message and forwards it to my system, then receives the second part and forwards it to my system independently.
Is there are way to make sure multipart messages are concatenated properly in Kannel?
You can set in core group:
sms-combine-concatenated-mo = true
I have many instances of my client application. These clients send requests to a server application via messaging and receive a reply. Normally the reply would be sent using a temporary queue.
Unfortunately I have to use the Stomp protocol which has no concept of temporary queues or topics. (Although the message broker has)
What's the best way to ensure only the original requestor receives the reply? Are there any best-practices for this unfortunate situation?
The customary solution when several requestors listen for replies on the same queue is to use correlation IDs to select messages. On the client side it looks like this:
Place a message on the request queue and commit.
Retrieve the JMSMessageID from the outbound message (the value is determined by the broker and updates the message object as a result of the send).
Receive a message from the reply queue specifying the JMSMessageID from the outbound message as the correlation ID in the selector.
Process and commit.
On the server side it looks like this:
Receive a message under syncpoint.
Process the request and prepare the response.
Set the JMSCorrelationID on the response to the value of JMSMessageID from the request.
Send the message.
Commit.
The consumer would set the selector something like this: activemq.selector:JMSCorrelationID=.
Since the broker creates a message ID that is supposed to be globally unique, the pattern of using it as the correlation ID prevents collisions that are possible when each requestor is allowed to specify it's own value.
The best way to implement this pattern with JMS (that I've found, anyway) is to create a pre-configured topic for the response messages, and use correlation selectors on the response message so that the client can get the correct one.
In more detail, this means setting a random ID on the request message (using setJMSCorrelationID()), and putting that message on the request Queue. The consumer of that request message processes it, creates the response message, sets the same correlation ID on the response message, and puts it on the response Topic. The client, meanwhile, is listening on the response topic with a selector expression which specifies the correlation ID that it's expecting.
The danger is that the response message is sent before the client can get around to listening for it, although that's probably unlikely. You can try using a pre-configured Queue for the responses rather than a topic, but I've found that topics tend to work more reliably (my JMS provider of choice is HornetQ - your mileage may vary).
All this is tell me that JMS is a very poor fit for the request/response model. The API just doesn't support it properly. This is hardly surprising, since that was never a use-case for JMS.
Something like a compute grid (Terracotta, Gigaspaces, Infinispan, etc) would likely yield better results, but that's not really an option for you.
I have problems implementing SMTP protocol over WinSock API. Here's what I do now. The client creates a non-blocking socket, connects to the server and exchanges data with it.
It uses "send string" primitive which efectively calls send() in a loop until the whole string is transmitted and "receive string" primitive which calls recv() in a loop until a string ending with CRLF is accumulated or timeout occurs.
The above dumb approach works, except on one specific server deployed at the customer's site. On this server the client sends EHLO, AUTH, MAIL FROM, RCPT, DATA, each time receiving a reasonable responce. Then it sends the mail message body line-by-line (not trying to receive anything from the server) and after some time send() (several hundred lines sent) stars returning WSAEWOULDBLOCK.
How do I handle this? Do I have to check for pending input on the socket after each line? Or what else should I do to predict and possibly prevent this situation?
From the documentation:
This error is returned from operations on nonblocking sockets that cannot be completed immediately, for example recv when no data is queued to be read from the socket. It is a nonfatal error, and the operation should be retried later.