| "SMSCRoute" and TLV for Routing in SMPP |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 23, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 65 Registered: 06-2004 |
Des, Bryce: There is a description in this post on use of TLV to define routing: http://support.nowsms.com/discus/messages/1/24485.html Could not quite understand if it's possible to make messages received in NowSMS via SMPP from ESME-s (clients) to route upstream to SMSC-s using TLV in received messages. Imagine we have two SMSC definitions. One is SMPP - smsc1:1111 with a RouteName=SMSC1 and the second SMPP = smsc2:2222 with a RouteName=SMSC2. What else should we include in the smsgw.ini file and what TLV should be present in messages from User A, sys_id=user_a to submit via SMSC1 and those in messages from User B, sys_id=user_b so that they submit via SMSC2? Can you please provide some simple example? Thanks! Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1563 Registered: 08-2008 |
Hi Ashot, I'm going to defer to Bryce on this one. He should be back tomorrow. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1571 Registered: 08-2008 |
Hi Ashot, I'm wondering if the other approach that you're discussing in http://support.nowsms.com/discus/messages/1/42107.html would be better. (If it worked on best match.) To use this approach, you just need to be able to specify a TLV parameter from the ESME client. On the NowSMS side, you configure under an [SMPP] section header of SMSGW.INI, SMSCRouteTLV=####, where #### is the SMPP tag number (in hexadecimal) to be used for this TLV parameter. In the ESME client, you include a TLV parameter using this tag number and the NowSMS route name as a null terminated string value. Using a service_type value, as discussed in the other thread, would probably be easier to configure in an ESME. I'm pushing to get a resolution to the question raised there before the holidays. -- Des NowSMS Support | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 69 Registered: 06-2004 |
Hi Des, We've just tested it with TLV routing, works great! Can you please confirm that the tag is removed once the message has routed and submitted upstream? Leaving it would be a good idea if a special configuration option is indicated, such as "RetainTagValue=Yes" for each SMSCRouteTLV=####. That would allow for forced routing via a chain of NowSMS servers (e.g. each analysing its own tag(s)) but remove the tags at the last uplink in the chain, so that the SMSC upstream does not get an unexpected value. It'd be also quite important to have the TLVs used for routing record in NowSMS SMSOUT logs for each message. Is there also a possibility or reverse routing by TLV? If a message (as opposed to a DLR) is received from a NowSMS SMSC connection and it contains a tag value, the tag is specified for reverse routing and the value is matching that of a user account sys_id, the message would always route via that user account. Ideally, this should also work if the tag value in an inbound message from an SMSC connection matched that for another uplink - the message flow reverses and it submits over another SMSC uplink. We understand though that addressing proper routing of DLR for such reverse-flow message scenarios is hardly possible without full support of data_sm and flexible conversion between submit_, deliver_ and data_sm and proper ESM Class conversions for such scenarios, which must be more than a regular support task. This is now being discussed between our commercial departments. Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1575 Registered: 08-2008 |
Hi Ashot, The tag is definitely removed when the message gets routed upstream. I should note that in addition to NowSMS interpreting this value, it does gets inserted when NowSMS delivers a message to a client to indicate the route from which the message was received. Another NowSMS could preserve the value from another server by using a custom [SMPPOptions] setting. There's not much more to tell about this particular setting. It doesn't have any support for reverse routing into a user account. Whether or not it could ... I don't know. I'm not sure that I follow the rest, or maybe I do... I think you've raised the issue before that many SMSCs do not expect to see the esm_class value indicating that a message is a receipt when a message is received via submit_sm. Looking at the SMPP spec, I do see a reference that a delivery receipt is carried as user data payload in a deliver_sm or data_sm operation ... not submit_sm. I gather this particular scenario would only occur if you are using the "ReRouteReceived" setting, which causes a deliver_sm receipt to be converted to submit_sm ... when it should be data_sm. Is my interpretation correct? -- Des NowSMS Support | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 72 Registered: 06-2004 |
Hi Des, I need a bit more clarification.. .. in addition to NowSMS interpreting this value, it does gets inserted when NowSMS delivers a message to a client By "Client" do you mean a User Account? to indicate the route from which the message was received. By "Route", do you mean an SMSC? In other words, are you describing a scenario where the message was received from an SMSC as a deliver_sm and routed by NowSMS (downstream) to a User Account? If so, you are actually referring to Reverse message flow, from SME (SMSC) to ESME (user connected to NowSMS.) Another NowSMS could preserve the value from another server by using a custom [SMPPOptions] setting. There's not much more to tell about this particular setting. Can you please describe in more detail how this option works, preferrably with an example? It doesn't have any support for reverse routing into a user account. Whether or not it could ... I don't know. You've lost me here.. As for reversed DLR and data_sm: Your interpretation is correct, but there is a lot more to this. We are prepared to write a detailed spec on how in our opinion this should be implemented, if we knew that you'd consider undertaking the extra development. This is a separate complex subject, so I've posted preliminary notes on it in a new discussion. The spec would deal with support for data_sm and converting messages and receipts from submit_, deliver_ and data_sm on both inbound and outbound connectors (User accounts and SMSC uplinks) in various message flow scenarios. This part will be strictly according to the SMPP specification. There will also be a somewhat custom part: support for Transaction Mode. We'll spec it according to the most common Logica/Cisco implementation and would give you access to a Windows server in the same LAN with a live SMPP/SS7 FDA gateway, so that you can test it in real envirnment while developing. I think it'd be an exciting experience: these boxes support thousands of concurrent TX sessions per bind with a window size 100 each without dropping sessions or packets while processing thousands of concurrent TCAP dialogues on the SS7 end and proxying the SS7 resps back to SMPP. It is a real working solution allowing to push several hundred SMS/sec. (up to 30,000 SMS/sec. on the larger machines) in Transaction mode without causing havoc due to timeout/resubmits. Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1591 Registered: 08-2008 |
Yes, I'm referring to a "user account" defined on NowSMS. If the message was received from an SMSC as a deliver_sm, and it gets routed downstream to a "user account", then this TLV parameter is inserted in the deliver_sm. I'll read the other message for other details. -- Des NowSMS Support | |||
