| SMPP v3.3/3.4 Compliance |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
1) I dont see configuration options for SMPP parameters like TON,NPI in SMSC menu 2) I tested the bulit in SMPP server with another commercial SMS gateway but the connection drops when KEEPALIVE/ENQUIRE_LINK signal is sent by the 2nd gateway | |||
| Bryce Norwood - NowSMS Support (Bryce) |
1.) That's because the default settings that we use are suitable for 99% of the configurations. (We vary the value based on whether you provide a number in international format starting with a "+" or not ... as well as if the sender address is alphanumeric we detect that and set the values appropriately.) So far I haven't seen a configuration where we had to override the default settings, but if necessary, we'll provide a way to override. 2.) I'd have to see a log file to understand what occurred. We do support the enquire_link command, so I'd be curious whether we dropped the connection because we didn't like something in their request, or whether they dropped the connection because they didn't like something in our reply. You can enable the debug log by manually editing SMSGW.INI, and adding Debug=Yes under the [SMSGW] section header. Then restart the gateway. There will be an SMPPDEBUG.LOG that logs all SMPP activity. You can forward that to nowsms@now.co.uk if you'd like clarification on what is occurring in a particular situation. -bn | |||
| Anonymous |
Thanks, Few more SMPP parameters: SERVICE_TYPE, VALIDITY_PERIOD, RETRY_COUNT, ENQUIRE_LINK_PERIOD are to be used ..any help | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Hi, "Service Type" is a "per message" setting, specific to SMPP (it doesn't map to anything in the underlying SMS protocols, it is a grouping used by an SMPP-based SMSC itself). If we supported this setting, would you want it to apply globally to all messages submitted by your system, or to apply on a message-by-message basis? "Validity Period" can be set via an entry in the SMSGW.INI file. Manually edit SMSGW.INI, and create an [SMPP] section, then define ExpiresHeader=SMPPtimeformat. (For example, 7 days would be ExpiresHeader=000007000000000R) The SMPP time format is documented in section 7.1 of the SMPP v3.4 spec, which I've excerpted at the bottom of this message. As this setting will currently apply to all messages, you'll want to be sure to use "relative" format. "Retry Count" is not a parameter that is settable via SMPP. Instead, it would apply to the gateway itself. The retry count is currently hard coded for 10, with some exceptions. In the SMPP environment if the error code is ESME_RTHROTTLED or ESME_RMSGQFUL, the gateway gradually slows down retry attempts, but retries indefinitely assuming a problem at the SMSC or with the SMSC account. If the error code is ESME_RINVDSTADR (invalid recipient address), then no further retries are attempted. The enquire link period after which the gateway generates an enquire link after a period of inactivity is hard coded for approximately 60 seconds. However, the gateway will respond to any enquire links initiated by the server, so the server is free to send enquire link at its own pace. ----- SMPP Time Format In this interface, all time/date related fields will be in ASCII with the following format: “YYMMDDhhmmsstnnp” where ‘YY’ last two digits of the year (00-99) ‘MM’ month (01-12) ‘DD’ day (01-31) ‘hh’ hour (00-23) ‘mm’ minute (00-59) ‘ss’ second (00-59) ‘t’ tenths of second (0-9) ‘nn’ Time difference in quarter hours between local time (as expressed in the first 13 octets) and UTC (Universal Time Constant) time (00-48). ‘p’ - “+” Local time is in quarter hours advanced in relation to UTC time. “-” Local time is in quarter hours retarded in relation to UTC time. “R” Local time is relative to the current SMSC time. Note: Where responses are reported by the SMSC the local time of the SMSC will be given, and the format will be “YYMMDDhhmmss”, with the same definitions as above. 7.1.1.1 Absolute Time format This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol ‘+’ or ‘-’. 7.1.1.2 Relative Time Format Relative Time can be indicated by setting the UTC orientation flag to ‘R’ instead of ‘+’ or ‘-’. In this form, the SMSC interprets the time format as the number of years, months, days, hours, minutes and seconds from the current SMSC time. Values for tenths of seconds ‘t’ and UTC offset ‘nn’ are ignored and should be set to ‘0’ and ‘00’ respectively. For example, the following time format ‘020610233429000R”: - would be interpreted as a relative period of 2 years, 6 months, 10 days, 23 hours, 34 minutes and 29 seconds from the current SMSC time. Note: An SMSC operator may choose to impose a limit on relative time offsets, thus either rejecting a message that exceeds such a limit or reducing the offset to the maximum relative time allowed. For example:- a typical validity period might be 7 days and a typical scheduled delivery times might be 14 days from the submission time. | |||
| Anonymous |
SERVICE_TYPE, VALIDITY_PERIOD and RETRY_COUNT are the parameters which we normally use for individual messages. e.g. Stock alerts carries a VALIDITY_PERIOD of max 30 mins, but Headline News may be valid for 6-7 hrs. similarly SERVICE_TYPE in our case defines billing parameters, varying from basic to premium for ringtones etc. Would definitely like to see these as default parameters but at the same time could be overridden by any message specific parameters, if required. -Thanks | |||
| Bryce Norwood - NowSMS Support (Bryce) |
I understand. But maybe I should ask what you are trying to accomplish. Are you looking to be able to set those parameters when submitting via the web interface? Or are you looking to submit those messages via SMPP, and have those parameters maintained when routed to another SMPP server? Right now, we don't do either of those things, but we are looking to improve the interface that allows other SMPP clients to connect to us as a server in future releases. So we're trying to better understand what type of uses for this functionality people have. -bn | |||
| Anonymous |
I would say, looking for these parameters on: 1. HTTP interface to have these parameters as options, allowing user to define them for individual messages. 2. When using NowSMS as a VSMSC via SMPP these parameters need to be maintained and delivered to another SMPP server or SMSC. This actually means, other SMS gateways connecting to it with each having its own parameter definition on message-by-message basis. I feel VSMSC is a very strong feature of the application and would like it to be complaint with SMPP specs. as much as possible. Would consider using it in a high scale, carrier grade environment. -Lika | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Hi Lika, We're going to look at maintaining more of the source SMPP settings when used as a VSMSC in a future release. I'm not sure how far we'll go on the web interface ... except with parameters that can also be expressed with relevance to the other types of SMSC connections. (In other words, if a setting is SMPP specific, like TON/NPI, it is unlikely that we'd add support for it in the web interface. By contrast, expiration settings can be mapped into different interfaces, so that is something that would be a good candidate for the web interface.) We have to get through the MMS-related updates in the next release of the NowSMS product. Once we get past that, enhancing capabilities in this area is toward the top of our list. -bn | |||
