I've buyed a 2n (http://www.2n.cz/en/) GSM gateways, exactly the VoiceBlue Lite (4 port, http://www.2n.cz/en/products/gsm-gateways/voip/voiceblue-lite/) mainly as a ''GSMBox'' use, but i've tried to experiment in sending SMS.
For now i'm experimenting using a bit of perl and expect perl module, butwill be cool to use SMSServer3!

Reading the manual (http://www.2n.cz/download/2/0/3/vbl-manual-2.6.pdf) and poking around seems that my gateway was simply a ''wrapper'' built around four Siemens/Cinterion MC55i modules (http://www.m2mportal.ru/lib/mc55i_atc_v01201.pdf).
The box have ethernet, usb and rs-232 connectivity, AFA the manual say, all export the same AT-command interface.

Reading the manual i've also understood that there's substantially two modes of sending SMS.

1) using an AT ''prefix'' command that send the AT command directly to the specific GSM interface, eg:
AT&G0=ATI
send the command ''ATI'' to the first MC55i module; i've successfully send some message using this, but was proven to be very unreilable, or i was really ignorant about SMS AT commands...

2) using a simplified interfaces provided by the box itself; the interface works entering in ''SMS mode'' with AT!G=A6, then working with SMS with only 5 commands (list, read, delete, send to module or to group of modules) that accept only PDU data. Then you have to exit from SMS mode with AT!G=55.
This mode works flawlessy (again, with my AT command and perl knowledge...).

Seems to me that SMSTools3 can be use mode 1) with little or no modification, but probably require major sessions of debugging and trial and error to made reilable.

I think that mode 2) will work, but require the writing of specific code (even if simpler and not complex one, AFAIK).

Reading other forum seems to me that all 2n devices behave similary, so probably implemementing ''simplified PDU mode'' would support all 2n devices, or at least most.

Unfortunately my GSM, SMS and C language knowledge are very poor...

I already had a "multiplexer" written, which allows multiple modems to be used through the single interface. It worked pretty well, but not with 2N device because there is a bug in the Gateway. You probably have seen that in the other topic, but I still include it here:

Quote

From the log of smsd it can be seen, that the module was trying to give the prompt, but the gateway did not deliver it to the serial port at the correct time:

GSM0: -> at&g0=AT+CMGS=19
GSM0: Command is sent, waiting for the answer. (20)
GSM0: Incorrect answer, put_command expected (>)|(ERROR), timeout occurred. 1.
GSM0: time 20527 ms <- at&g0=AT+CMGS=19  <++g00     AT+CMGS=19
GSM0: -> at&g0=001100099106368895F00000FF0673F29C3C2703.
GSM0: Command is sent, waiting for the answer. (60)
GSM0: time 505 ms <- -->g00     >   -->g00     +CMS ERROR: 500 OK  (Unknown error)

The answer which was received before timeout expired is shown in green, and it contains first two lines only. After the next command is sent to the gateway, missing prompt is received. It's shown in red.

This bug means that 2N Gateway cannot be used with standard AT commands, even when those commands are supported...

The "simplified interface" is also "very limited" interface, which allows only single modem to be used at a time. Missing features, like signal quality, registration status, phonecalls etc.. likely are not a problem. What SMSTools3 will need, is a MUX device (like a modem process) which talks with the Gateway and places incoming messages to the shared memory of appropriate modem process, and gets outgoing messages and sends them using the correct modem. Basically it's not very complicated to code, but many other things should be handled too. For example, if there are four processes sending messages, and 2N can handle only one modem at a time, there will be long delays and timeouts should be changed. And if smsd is stopping when a message is not yet sent, it should be handled properly. And so on...

I have to think what to do with this 2N Gateway, but right now I do not promise anything. If I add 2N specific features to the SMSTools3, those features should be supported in the future too. It may be slightly difficult, because I do not even have this kind of a 2N Gateway...

gaio - Can you send me your perl scripts? My email: ireneusz (dot) baka (at) gmail (dot) com.
Thank's in advance.

keke wrote

The "simplified interface" is also "very limited" interface, which allows only single modem to be used at a time. Missing features, like signal quality, registration status, phonecalls etc.. likely are not a problem. What SMSTools3 will need, is a MUX device (like a modem process) which talks with the Gateway and places incoming messages to the shared memory of appropriate modem process, and gets outgoing messages and sends them using the correct modem. Basically it's not very complicated to code, but many other things should be handled too. For example, if there are four processes sending messages, and 2N can handle only one modem at a time, there will be long delays and timeouts should be changed. And if smsd is stopping when a message is not yet sent, it should be handled properly. And so on...

I've not understood (really: never tried to... ;-) how SMSTools3 works, but in my experience a simple poll (connect, send PDU data, wait for error or ok) do the job. For MUXing, consider also that you can define a  group  in the GSMBox and send messages to the group: it is the box itself that muxes messages between the SIM...

keke wrote

I have to think what to do with this 2N Gateway, but right now I do not promise anything. If I add 2N specific features to the SMSTools3, those features should be supported in the future too. It may be slightly difficult, because I do not even have this kind of a 2N Gateway...

As just stated in private email, if you need i can provide support for this...

gaio wrote

I've not understood (really: never tried to... ;-) how SMSTools3 works,

Take a look at the slideshow. In the page 2 the is explained how multiple modems and queues work. There is also bigger picture available.

The picture is very old and somewhat inaccurate. There is shown that "Sent" and "Incoming" messages comes from the SMSD "main program" to the "Sent Folder" and "Incoming Folder", but this is not how things are working. Those messages comes from the "modem handlers". Also, "eventhandler" is executed by the modem handlers, not by the main program. However, let's not let this interfere...

If queues are not defined, all modems will serve the same "Checked Folder". All messages from the "Outgoing Folder" are placed into the "Checked Folder". The modem which see the message first, will send it.

When queues are defined, all modems have a definition of queues which are served by that modem. The picture is of such a situation. There is modem1 which is serving two queues, and other modems are serving single queue only. Take a look at the Configuring providers to see how the sorting works. When queues are used it is also possible to define the modem to be used in the message file. For example, if queues are named like modems are, a header Queue: GSM1 can be used for selecting the first modem.

In many applications it is important that modem can be selected. Also, in the receiving side messages from different modems may be handled in different way, and because of this there is a Modem: header available in the incoming message file. All modems can also have different eventhandler script for handling messages, if necessary.

From SMSTools3's point of view, four modems inside the 2N Gateway should be seen as four different modems, not as a single "modem handler" which tries to handle four modems. In theory single process could manage more than one modem, but then additional headers for outgoing message file are required. Users want to select the modem to be used, and provider sorting will not work if all modems are "GSM1". There should be some header like "2N_module: 1", and this causes changes to the original design of smstools. Also, all incoming messages would be from "GSM1", and again additional header is required to tell what module received incoming message.

gaio wrote

but in my experience a simple poll (connect, send PDU data, wait for error or ok) do the job.

"Simple poll" surely has been working with your perl script, there is no doubt about it. SMSTools3 could also use "simple polling", but it is not enough because there are more than one processes which need to handle the same interface. This cannot be done simultaneously, which means that there should be some kind of "scheduling" for usage of the interface, or multiplexer.

As you have a working perl script, do you have a log file which tells how things are going when all modules are used simultaneously for sending lot of messages, receiving lot of messages and receiving lot of status reports? And at the same time there should be phone calls, which (probably) will reserve the interface (because it's used when a call is initiated). And probably some SMS traffic created by the Gateway itself, collisions etc. etc.. If you have this kind of a log, with timestamps and commands presented, it would be very interesting to see.

gaio wrote

For MUXing, consider also that you can define a  group  in the GSMBox and send messages to the group: it is the box itself that muxes messages between the SIM...

Yes, I know that with 2N Gateway message can be sent using any module, or using any module in defined group, or using a certain module. The latest way is the way how SMSTools3 wants to send (and also receive) messages. This is because the modules should be seen as GSM1, GSM2 etc. and SMSTools3 wants to talk with exact SIM, not with "some random" SIM. For example message counters also require that SIM is exactly known.

gaio wrote

keke wrote

I have to think what to do with this 2N Gateway, but right now I do not promise anything. If I add 2N specific features to the SMSTools3, those features should be supported in the future too. It may be slightly difficult, because I do not even have this kind of a 2N Gateway...

As just stated in private email, if you need i can provide support for this...

I still have to think ... Thank's for you offer, but we do not yet know what would be the amount of support, and what amount could be possible for you and your requirements. In any case, I will not add "partial" or "simple" features to the SMSTools3, because later I will be in trouble with them. Only complete solution should be possible, and that's much more than just some couple of lines of a code.

On the other hand, as you already have the script, why not to continue with it in the future too?

Anyways, I'm thinking and looking forward if you can provide the log mentioned...

keke wrote

"Simple poll" surely has been working with your perl script, there is no doubt about it. SMSTools3 could also use "simple polling", but it is not enough because there are more than one processes which need to handle the same interface. This cannot be done simultaneously, which means that there should be some kind of "scheduling" for usage of the interface, or multiplexer.

Sure, muxing is needed, but consider that every reply from the GSMBox report contain the SIM or group that generate the event, and there's also a sort of ''index'' number, so if you expect a reply you can correlate.

keke wrote

On the other hand, as you already have the script, why not to continue with it in the future too?

Sure, for now i will do that, probably with a simple (ok, stupid perl daemon that receive PDU and send them.

Again, thanks,