[Jeff Blees]

[Jeff Blees]

Hello Herraiz,

Multi-Tech offers a DC power cable.

This DC power cable is 5 feet long. One end is the screw on/locking barrel (to the back of the MTCDP) the other end is two bare wires (to the DC source).

You can order and purchase through our Customer Service department.

eorders@multitech.com

Multi-Tech ordering model number PC-932-DC.

MSRP US$ 6.00

If you would like to see a datasheet/drawing (contains specs on barrel connector) please me mail me at:

salesfae@multitech.com

Sincerely

Jeff Blees

[Jeff Blees]

Hi Alex,

Thank you for the feed back.

With regards to the iSMS server product line, we are aware of – others have requested, that we improve/expand our API command set with regards to system status, management type functions, etc.

Currently, system management and performance is performed through port 80 with a Web Browser (reviewing the contents of various menu). Currently, no changes in this area are planned.

I believe our “priority” option does not effect through put (how many messages we send per minute). We have only one send queue and the priority option helps dictate which message we should send next.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Upon receipt of the SMS from the wireless cloud, this iSMS server will try 3 times in a row to POST the message to the server. If the POST attempts are unsuccessful, the message will be placed into the Receive API Failure log and is not be re-sent / re-queued. The message is also placed in the Inbox and Received SMS trace log. The originator will have to resend once the net server is back up or the net server administrator will have to manually review the iSMS server to learn what messages came in while the net server was down.

The Polling method of Receive API was implemented to address this concern.

Sincerely

Jeff

[Jeff Blees]

Hello Jan,

We’re sorry for the delayed response.

WAP-Push is not supported.

Regards

Jeff

[Jeff Blees]

Hi Brian,

We’re sorry for this delayed response (an update to this forum should of been posted in mid March but was not). Engineering research revealed the amount of work needed to implement such a feature is very significant. Currently there is no plan to implement this type of feature.

Sincerely

Jeff

[Jeff Blees]

Hi Kirk,

We’re sorry you didn’t get a response right away through this forum. I see that you had to open a support case through our WEB portal and were then able to close out the issue.

I just wanted to post your findings to this thread. Please Note: We added that <Response> element to our XML data structure in iSMS version 1.44. I’ll mention to the Engineer of the C# example code to update the example.

Thanks

Jeff Blees

Engineering Technician

Kirk Wrote:

Figured it out. The iSms was doing everything as configured. On my default.aspx page I had to set ValidateRequest=”false” otherwise IIS thought it was malicious code being sent and rejected the post.

Also, in the C# code sample MultiTech has this line

XmlNodeList xmlNodeList = xmlDoc.SelectNodes(“/MessageNotification”);

I couldn’t get that to work so I changed it to

XmlNodeList xmlNodeList = xmlDoc.SelectNodes(“/Response/MessageNotification”);

[Jeff Blees]

Hello Avrom,

The FaxFinder does not support the use of traditional Caller ID (FSK signal in-between 1st and second ring on analog line).

The analog line (usually an extension port on a PBX) needs to provide/transmit a string of DTMF digits to the FaxFinder port, right after the FF port goes off hook to answer the ring.

The string of DTMF digits is usually the last X number of digits dialed by the originating/calling side fax machine (AKA the DID digits).

After we receive the DID digits from the PBX, we proceed to answer as a fax machine and negotiate the fax. After we have completed the fax session/call – we then look to match the string of DID digits with an email address in our Fax Recipient routing table (so we know who to email the received fax to).

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Kirk,

I’m sorry but I can’t find a record of us working together before (maybe you were working with Jeff Kline – you have some cases in our Portal with him).

Neither your initial comments or my reply, in today’s thread, say anything about the iSMS not working when a log file becomes full. Are you having a failure?

Emailing the logs is part of a maintenance function. If you do not want to receive the periodic emails – “delete” the “Log File Full” item in the “Send Email Notification for” column in the Administration menu. Then when the log file becomes full, it gets renamed and backed up locally in the /var/log/ folder on the iSMS server. Then after 3 cycles of it being backed up/renamed – it gets deleted.

I’m not sure what all the variables are to the msgid number that is generated by our send API.

I know if you default the box it will start over.

I goes up to at least 99999.

A system reboot/restart does not cause the number to start over.

If your APP uses (submits to more than one) iSMS server, then Yes, you will have to track separately. The msgid generated by each iSMS server is independent of the other server.

There is an alternative to this. You can utilize our “Load Balancing” feature – however it’ really not a balancing feature. It’s more of load sharing when I get too busy feature. The current online User Guide is quite accurate with it’s description of the feature. You only have to submit to one unit, but you have no control over which unit is used to send out the message.

I’ll look into the msgid rollover question more and get back to you.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Kirk,

The system is some what liberal when it comes to phone numbers. I do not know the behavior for all possible scenarios (but I think the following covers most).

If the number you tell us to send to is not valid (rout-able by Telco), Telco will respond back with an CME error (usually error CME: 21). For scenarios that result in a CME error, we will try to send it 3 times and if all 3 attempts result in a CME error, it will then be listed in the “SMS Failure Log” trace.

If you submit a number that contains a non-numerical character, we will strip it our and then submit to telco (dial) the remaining string.

We do not attempt dial strings that surpass the total number of digits defined in our “International Number” menu (SMS Services menu) when the “Disable International Number” option is checked (which is on by default). If a message is submitted with a To Number that surpasses the max length, we accept it from you, but then never try to dial it (it too will instead be listed in the SMS Failure log). If this International Number option is not checked, we do not look for a maximum length (however there probably is a max length for the To phone number input field of the Send SMS menu).

If the number you’ve submitted to us, is less than the max length defined in the International Number menu – we’ll try to send to it (for scenarios related to within the same area code, and sending to a “short code” number).

Regarding the Log File Full email notifications. We have various logs in the system – when any one log fills up, it will be emailed to the administrator (when the email option is enabled – see administration menu – the option is off by default). The emails do not specify which log it is – you have to open the attachment to know).

Being you are mentioning this log file full email – perhaps you are receiving too many for your liking? There could be more than one reason for this.

Do you have a multi port unit, that has all it’s ports enabled, yet not all ports have a SIM physically installed? Ports without a SIM should be “unchecked” in the Cellular Modem setup menu (sub menu of the Network Setup menu). Otherwise we constantly try to init modem – which leads to a full log file rather quickly.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hello Yemane,

We do not test with Kannel. Regardless of which Software & or platform you are trying to use, all have to communicate the same way with the iSMS SMS Servers (via API based commands).

Here is a link to various pieces of sample code.

https://webfiles.multitech.com/engineering/sample-code/sms-finder/

Our API commands start on page 74 of the User Guide.

http://www.multitech.com/en_US/DOCUMENTS/Collateral/manuals/S000461B.pdf

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hello Alex,

The “inbox” (per port) is essentially just a log of what messages the particular port (modem with sim card) has received from the cellular network.

The contents of each inbox does not reflect if the SMS/text messages listed (in each inbox) was delivered or not to your host application.

The “Receive API query commands” do Not implement/need/use a modem number specific option (“filter” option).

The “Send API commands” that we support/use Does include a modem specific option so you can pick which sim/account you want to send out SMS messages through. Maybe you are confusing this send function with our receive function?

Even though the WEB menus display an “inbox” per port – all SMS messages that come from the mobile network, regardless of what modem port they came in on, are held in our “receive queue”. Depending on how you set up our Receive API – you either query our pool to get the sms or we automatically post the message to your host application. The response we give/post contains (among other things) which port the SMS was received on.

How do you have the “Non Polling Receive API Configuration” section, of the “SMS API” menu, configured?

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hello Raza,

The iSMS is compatible with any software/application that can utilize/conform to the specific API commands implemented by the iSMS SMS Server.

Please review our API Appendix starting on page 74.

http://www.multitech.com/en_US/DOCUMENTS/Collateral/manuals/S000461B.pdf Check

SMSlib needs to submit messages to us, via HTTP, following our documented syntax.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi David,

If you have only 1 SIM in the SF400 – are the other 3 ports disabled? The “Status” check box for each port without a SIM card needs to be unchecked (this is found in the “cellular modem” setup page within the Network Setup menu).

If you have not already, please open a case in our support portal. http://www.multitech.com/en_US/SUPPORT/

The iSMS does not have a setting that dis-allows the sending of duplicate messages. I know from testing it can send duplicate messages over and over.

What is the contents of the HTTP Send API Live Log (it’s a log of what you submit to us) and what is the contents of the “SMS Live Log” (a per port log of how our SMS server controls/utilizes the modem)?

Even though both are T-Mobile SIMs, the problem could still be with one SIM? Have you tried swapping the SIM cards around?

What version of firmware is the SF400 running?

Is the failure all the time – or does it follow the contents of the SMS?

Can you send a simple short sms (twice in a row) that does not contain any blank lines like “Hi, this is a test.”

Can you send a simple sms via our Send SMS GUI menu, twice in a row?

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Brian,

There has not been any decision on adding this. Today I asked if Engineering could give any additional details.

My simple understanding of how the iSMS product currently works (current API commands, GUI menu choices and how our cellular modem is currently communicating with Telco) suggests to me that adding this would be at least a somewhat significant change & require a fair amount of testing – however I’m not a software engineer and so I’ve asked Engineering to look into this aspect and determine what it might take to add this functionality.

I think maybe by the end of the week – more information on this perspective should become available.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hello Cole,

The FFx20 product line does not have an API. Any note about supported platforms would be in reference to the FFx30 product line.

We sincerely hope you have a safe and happy new year.

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Matt,

Have you reviewed our Perl examples and how to found at:

https://webfiles.multitech.com/engineering/sample-code/sms-finder/perl/

? If not, please do.

When you say “I am able to send messages straight from a browser, but…” – do you mean using a browser to access the iSMS server on port 80 and navigating our menus to send with?

How do you have all of the options set in the “SMS API” menu (found in the SMS Services menu)?

Have you reviewed the API appendix in the administrators user guide (starting on page 74)?

http://www.multitech.com/en_US/DOCUMENTS/Families/MultiModemiSMS/manuals.aspx

Lots of customer’s are using Perl scripts to send out text messages through iSMS server.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Mark,

I take it you are submitting messages via our HTTP Send API function/process. Our Send API provides a MsgID Number in response. You can then perform a MsgID query to track the progress of our transmitting the SMS over to Telco/service provider. This information is depicted in our API Appendix, in the current online Administrator’s User Guide.

We do not track if the Cellular Network has delivered the SMS to the mobile End point.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Mark,

I see you have opened support case 5025011 with us. My first re-action is one based physical location of the unit, the antenna’s and interference. I will update the support case with additional details and recommendations.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Anthony,

Sorry for the delayed response (I have been out sick).

Regarding SMS messages sent by the iSMS server (your previous question regarded messages received) – they are kept in one database, regardless of which port it was sent out on. This would be the “Outbox” data base in the SMS Services menu. We do not generate a text file of the numbers we’ve sent to.

As you submit messages for sending (via our API), you get back a MsgID number for each submitted message. You can then query for the status of that MsgID number – to learn if we successfully transmitted the SMS to Telco or not.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Feature #5024017

Products: SF400-G, SF800-G

Subject: Provide an option to merge per port Inbox into one Inbox

Description: Currently, SMS messages received from the cellular network are displayed per modem port (for the multi port models). Having the option to to review all received messages for all ports, in chronological order, would improve this administrative function.

Feature #5024020

Products: SF100-G, SF400-G, SF800-G

Subject: Display Sender’s Name instead of Sender’s Cell Number

Description: Add an address book lookup function/step before displaying/adding a received SMS to our Inbox and Log Traces menus. This way we can display a name if the sender also happens to be a contact in our Address Book. Telco only provides the number of the SMS Sender. If we do not have an entry in our address book that matches – then display the number.

[Jeff Blees]

Hello Anthony,

Currently, neither request is supported. Changes to the iSMS Server firmware would have to be made, to accomplish what you request.

I will write up a couple of feature request tickets. These tickets will become part of an existing database of feature requests that is looked at by the development Engineers.

Can you elaborate on how you are currently using your Multimodem iSMS SMS Server (application objective, volume of messages, etc) and what you potentially foresee regarding future expansion/additional units?

Regarding the second item (showing a name for the sender instead of a cell/mobile number) it would have to be tied to performing an Address Book search and finding a match. The cellular network only provides the number of the sms sender. If the sender of the received SMS is not listed as a contact in our Address Book, we would not be able to determine a name to display.

I will post the feature request ticket numbers once they have been created.

Sincerely

Jeff Blees

Engineering Technician

[Jeff Blees]

Hi Brian,

I’ve documented this feature request in our Engineering Development database (Ticket 1708).

Currently it is not known if or when this would be implemented. Initial discussions indicate adding this functionality would be a significant modification to the server’s software.

Sincerely

Jeff Blees

Engineering Technician

[Author]

Posts