| Mblox tlv's and smscroute with http smsc |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through August 10, 2011 ⬆ |
◄ ► |
| Author | Message | |||
| Frank Danielson New member Username: Fdanielson Post Number: 14 Registered: 02-2006 |
I've been doing some testing trying to send messages to an HTTP SMSC and have found that when using an SMPP SMSC or an HTTP 2way URL I can include option TLV's but can not in an HTTP SMSC. I've set this up on a test server using the latest 2011.03.21 patch. Is there a way to pass TLV parameters or the SMSCRoute to an HTTP SMSC? Here is an example from the SMSDEBUG.log- 23:07:46:937 [15] ThreadProcessConnection: Processing connection from 10.3.1.103:37343... 23:07:46:953 [15] ThreadProcessConnection: Processing request /?PhoneNumber=+14075551212&Text=Test+Text&Sender=12345&SMPPOption_mblox_tariff=1 99&SMPPOption_mblox_operator=cname 23:07:46:953 [15] Debug: 1 recipient entries 23:07:47:390 [10] ThreadProcessModem: Processing 0B34D096.req... 23:07:47:390 [10] ThreadProcessModem: GET /?PhoneNumber=15704000540&Text=Test%20Text&Sender=40404&SMSCRoute=@@SMSCROUTE@@& SMPPOption_mblox_operator=@@SMPPOPTION_MBLOX_OPERATOR@@&SMPPOption_mblox_tariff= @@SMPPOPTION_MBLOX_TARIFF@@ HTTP/1.1 User-Agent: Now SMS/MMS Gateway v2011.03.21 Host: 172.30.1.241:9090 Authorization: Basic dGVzdDp0ZXN0 Accept: */* Connection: close 23:07:47:421 [10] HttpResponseWait: ioctlsocket indicates end of request 23:07:47:421 [10] ThreadProcessModem: HTTP/1.0 400 Bad Request Content-type: text/html Expires: Tue, 01 Jan 1980 1:00:00 GMT Cache-Control: no-cache <HTML><HEAD><TITLE> Invalid Parameter </TITLE></HEAD><BODY><H1> Error: Invalid Parameter </H1> @@SMPPOPTION_MBLOX_TARIFF@@ </BODY></HTML> 23:07:47:421 [10] WaitForSocketClose: WinSock reported ioctlsocket complete 23:07:47:421 [10] ThreadProcessModem: Error: HTTPSMSC: Connection failed, HTTP status code = 400. Here's the SMSC config from the smsgw.ini- [HTTP - 172.30.1.241:9090] UserName=test Password=test TemplateText=/?PhoneNumber=@@PhoneNumber@@&Text=@@Text@@&Sender=@@SENDER@@&SMSCR oute=@@SMSCROUTE@@&SMPPOption_mblox_operator=@@SMPPOPTION_MBLOX_OPERATOR@@&SMPPO ption_mblox_tariff=@@SMPPOPTION_MBLOX_TARIFF@@ TemplateBinary=/?PhoneNumber=@@PhoneNumber@@&Binary=1&Data=@@Data@@&UDH=@@UDH@@& pid=@@pid@@&dcs=@@dcs@@&Sender=@@SENDER@@&SMSCRoute=@@SMSCROUTE@@ ServerType=Custom HTTPUseAuth=Yes SenderAddressOverride=Yes UseSSL=No ThreadCount=1 | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3294 Registered: 08-2008 |
Hi Frank, No ... the HTTP SMSC interface does not support passing any of the TLV parameters. (Or an @@SMSCROUTE@@ parameter ... in the case of the route, it would be fixed anyway, being the route for the HTTP SMSC.) It might be possible for us to add support for SMPPOption TLV parameters in the HTTP SMSC interface in a future update. But I'm curious about what you are trying to accomplish ... I'm assuming some sort of pass-through where you make message modifications? (I'm just wondering if it could be accomplished with accounting callbacks as an alternative, depending on what action you need to take.) -- Des NowSMS Support | |||
| Frank Danielson New member Username: Fdanielson Post Number: 15 Registered: 02-2006 |
I switched to an SMPP SMSC to get the TLV's. You are correct that I was trying to accomplish having the opportunity to make some modifications. In hindsight I can see that the HTTP SMSC interface is a different interface than the HTTP user interface. It would be nice to have the same parameters in both places, especially when the docs make mention of submitting messages to the HTTP SMSC via a 2 way command. | |||
| Frank Danielson New member Username: Fdanielson Post Number: 16 Registered: 02-2006 |
Hi Des- I'm working on a project where there are binds to a number of carriers and incoming binds from several sms aggregators. There are two challenges on mobile originated messages in this setup. One challenge is that each sms aggregator will be submitting traffic from a number of applications and instead of assigning hundreds of short codes to a user account in the NowSMS software (if that many can even be configured) it would be easier to use a callback to an external app for routing. From what I have seen the PreAuth callback only happens on mobile terminated messages, ie: messages submitted by a user account headed towards an smsc. Of course if PreAuth callbacks were available for messages incoming from an SMSC there would have to be some parameter in the callback request to identify the message direction. The other problem I'm trying to solve is that some carriers have more than one SMSC and each one has an SMSCRoute name and right now outgoing messages are routed to the proper SMSC using the PreAuth accounting callback to assign the correct SMSCRoute depending on the destination phone number. While that works great for mobile terminated messages, on mobile originated messages the SMSCRouteTLV is populated with the RouteName for that particular SMSC which means the application will get several different values in that TLV for one carrier depending on which SMSC the message came from which is confusing to some application providers. Ideally there would be a way to either manipulate that value in a callback or define in the smsgw.ini the value populated in the TLV instead of using the RouteName value. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3307 Registered: 08-2008 |
Hi Frank, I think I understand. Let me address the first challenge first. I assume that you are initiating the binds (connection defined in the SMSC list), which is why there is an issue. In this scenario, NowSMS assumes that the message is inbound, destined for either 2-way SMS processing, or a client account. It sounds like you want the message to go back outbound to another SMSC connection. If you put ReRouteReceived=any under the receiving SMSC connection header [SMPP - server:port], then NowSMS will redirect this from being an inbound message to being an outbound message, and perform the PreAuth and SMSSend account callbacks to get routing information. This is not necessarily a perfect solution, because this does not provide any option to choose either an inbound (e.g. 2-way SMS or SMPP client account) ... the ReRouteReceived setting means it can only be routed outbound. (Some more background on this scenario can be found here: http://support.nowsms.com/discus/messages/1/24779.html) For the second problem/issue, we did recently enhance the accounting callback interface to allow it to change source/destination addresses, as well as manipulate TLV parameters. Here is the description:
There is some related discussion here: http://support.nowsms.com/discus/messages/1/70053.html ... The current stable release that includes support for this change can be found at http://www.nowsms.com/download/nowsms20110620.zip. (We have not posted a general notice about this release yet, it is only discussed in messages on the forum here. There were some problems in interim versions between 2011.03.21 and this one, but these problems seem to resolved well in the 2011.06.20 version.) -- Des NowSMS Support | |||
| Frank Danielson New member Username: Fdanielson Post Number: 18 Registered: 02-2006 |
This is very good info. In the first challenge the mobile originated message will come in from an SMSC and it will go to a user account that is connected via SMPP (inbound bind). So if I do the ReRouteReceived bit and get to set routing info in the callback is there a way to specify the user the message gets sent to? The idea is to have a similar effect to using the &LocalUser=XXXXX on a message submitted via http. I'll definitely check out the 20110620 patch. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3308 Registered: 08-2008 |
That's the problem Frank ... ReRouteReceived=any triggers the "PreAuth" and "SMSSend" callbacks, but it assumes that the message will be routed to an outbound bind. I'd like to have it support the ability to route either to a local user (inbound bind) or outbound bind. We had a long internal engineering discussion about this awhile back, and I will have to reopen that discussion. In my opinion, the accounting callback should be able to return an "SMSCRoute=" response which allows the message to be routed to either an inbound or outbound connection. I'm planning to be on vacation next week, so I don't know that I will have any further update on this before I return. However, I will restart the internal discussion on this tomorrow. As it is currently implemented, there is no dynamic routing mechanism for routing to inbound connections. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3315 Registered: 08-2008 |
Hi Frank, I wanted to give you some follow-up information on this. We did some review on this issue, and believe that we have developed a good solution to address this in a soon to be released update. The "SMSSend" callbacks are being enhanced to support routing to either an external SMSC route, or a local user account. The way that it works right now, the "SMSSend" callback (PreAuth or normal) are allowed to specify the external route to be used by including a response of the format SMSCRoute=routename We are extending this support to allow a response format of SMSCRoute=localuser:accountname to route the message to a local user account. This logic only applies to routing outbound messages. However, if you put ReRouteReceived=any under the receiving SMSC connection header [SMPP - server:port], then NowSMS will redirect this from being an inbound message to being an outbound message, and perform the PreAuth and SMSSend account callbacks to get routing information, which will allow this logic to be supported. The configuration may be a little complex, but our review determined that this change could be made with minimal impact to other routing logic, requiring less development effort and less retesting. We should have an interim update available later this week so that you can try this functionality. -- Des NowSMS Support | |||
| Frank Danielson New member Username: Fdanielson Post Number: 19 Registered: 02-2006 |
This sounds encouraging and I look forward to testing it. Do you know if the Type parameter is set to SMSIn or SMSSend for the PreAuth callback when using ReRouteReceived=any? I'm trying to understand how my callback code would distinguish which direction the message is flowing. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3323 Registered: 08-2008 |
Hi Frank, The way it is currently implemented, it would be Type=SMSSend if the ReRouteReceived=any setting is in place. Ideally, I'd like to see the SMSIn callback support response handling so that this ReRouteReceived=any setting was not required. (It was designed for a different purpose.) However, changes to that logic are far more involved and would require more extensive testing. That said, there is a way for you to make this distinction. In the SMSSend callbacks (and related PreAuth), the "From=" field is the submitting user account. In the case of a message processed through ReRouteRecieved=any, it will be the SMSC id from which the message was received (e.g., SMPP - server:port). I should be posting this update in the next several hours. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3324 Registered: 08-2008 |
Follow-up. The update is at http://www.nowsms.com/download/nowsms20110705.zip. It should work like I described. -- Des NowSMS Support | |||
