Datagram mode

Datagram mode SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through April 16, 2015 » Datagram mode « Previous || Next »
Author Message
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 1
Registered: 07-2014
Posted on Thursday, July 31, 2014 - 04:28 pm:   

Hi,

Please can I change the value of messaging mode to data gram

Trace Messaging Mode
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4967
Registered: 08-2008
Posted on Friday, August 01, 2014 - 01:14 pm:   

Hi Walid,

There is currently no setting in NowSMS to enable this SMPP parameter.

However, I discussed this with one of our engineers, and they said it would be easy to add as a fixed parameter setting for all messages via a particular connection. It would be more difficult to add support on a per-message basis.

Would a fixed parameter setting for a connection work for your requirements?

I am also curious about what the application requirements are for using this parameter.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 2
Registered: 07-2014
Posted on Friday, August 01, 2014 - 01:19 pm:   

Hi,

Thanks DES to your quick reply :)

Yes, I need a fixed parameter setting for my requirements.

I want to connect to Ericson USSD Gateway installed to an african operator from nowsms.
All parameters are ok except the datagram mode.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4968
Registered: 08-2008
Posted on Friday, August 01, 2014 - 02:36 pm:   

Hi Walid,

That setting does make sense for USSD. We'll have an option added by Wednesday next week.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 3
Registered: 07-2014
Posted on Friday, August 01, 2014 - 02:42 pm:   

Hi Des,

Thanks to your reply !

so, by next Wednesday, I'll get the new option?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4969
Registered: 08-2008
Posted on Friday, August 01, 2014 - 02:46 pm:   


quote:

so, by next Wednesday, I'll get the new option?




Correct. We will have an update that adds this option by then.


--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 4
Registered: 07-2014
Posted on Friday, August 01, 2014 - 02:52 pm:   

Thanks and I'm waiting your update :)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4976
Registered: 08-2008
Posted on Tuesday, August 05, 2014 - 07:05 pm:   

Hi Walid,

An update is at http://www.nowsms.com/download/nowsms20140805.zip.

This is a description of the added setting:

* SMPP: Add configuration parameter to allow "messaging mode" values to be set for esm_class. This was necessary for a USSD interface that required the messaging mode to be set to datagram mode. To set the messaging mode, edit SMSGW.INI, and under the SMPP connection section header (e.g. [SMPP - server:port]), add MessagingMode=# to set the mode value (MessagingMode=1 for datagram mode).


--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 5
Registered: 07-2014
Posted on Tuesday, August 05, 2014 - 07:25 pm:   

Dear Des,


thanks to your reply.

it works properly now. many thanks!

however, when I try to establish a menu with reply. the ussd session seems to be expired at the third level (I send *194#, I got a response, and I reply with 2345 and I got a response, and I reply with 9123 and op! invalid mmi (on myy phone) and I receive on my platform "u_abort"). Can you help me please!

please find here attached the SMPP Debug and the SMS debug

thanks.
application/octet-streamSMPP Debug
SMPPDEBUG.LOG (43.2 k)
application/octet-streamSMSDEBUG
SMSDEBUG.LOG (28.1 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4977
Registered: 08-2008
Posted on Tuesday, August 05, 2014 - 07:47 pm:   

Can you try a different text string so that the response is not forced to Unicode?

I seem to recall that a different DCS value is used for Unicode in USSD. Some platforms may convert SMPP data_coding = Unicode to the appropriate USSD DCS value, but others may expect USSD DCS value for SMPP data_coding.

I see this note in an old update, which might apply:

* SMPP: Add configuration settings to force certain message types to use a particular DCS (data_coding) value on a per SMPP connection basis. DCS override values can be defined for all 7-bit text, binary and/or Unicode messages. For example, 0x0F is often the preferred DCS value for USSD text messages, and 0x48 is the preferred DCS for USSD unicode messages. When an override is applied, all messages of the specified type (text, binary or Unicode) will have their DCS value converted to the override value. To apply this setting for all messages routed to a specific SMSC, edit SMSGW.INI, and under the SMSC specific section (e.g., [SMPP - server:port]), add TextDCS=##, BinaryDCS=## or UnicodeDCS=## as appropriate, where ## is the DCS value in hex, e.g., TextDCS=F or UnicodeDCS=48.
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 6
Registered: 07-2014
Posted on Tuesday, August 05, 2014 - 07:58 pm:   

Hi Des,

I tried to change this scenario adn sending other reponse. but I had the same problem invalid MMI on the third level of exchange.

I put this config in SMSGW.INI. please find below my SMSGW.INI :

[SMSGW]
WebAuth=No
WebMenu=Yes
WebDisplaySender=Yes
WebDisplayRoute=Yes
WebPort=8800
ReceiveSMS=Yes
ReceiveMMS=No
PHPEnable=No
PHPAllowRemote=No
2WayReplyCopySMPPOptions=its_session_info,receipted_message_id
2WayReplySameServer=Yes
Modem1=SMPP - ussdServerIp1:7449
Modem2=SMPP - ussdServerIp2:7449
SeparateUserQueues=No
Debug=Yes
RetryMaxAttempts=1
AllowAlphaRecip=Yes
TrackSMPPReceiptsAlways=No

[2Way-Keyword-*]
Run=c:\Windows\SysWOW64\java -classpath d:\services;d:\services\mDjPayment.jar;d:\services\lib main.entrer "@@FULLSMS@@" "@@SENDER@@"
RunSendResponse=Yes
[2Way-Keywords]
Keyword1=*
[SMPP]
[SMPPOptions]
ussd_service_op=0501,Integer,1
its_session_info=1383,Integer,2
receipted_message_id=001e,HexString
[SMPP - ussdServerIp1:7449]
RouteName=ussd
SMPPVersion=v3.4
UserName=-----
Password=*****
SystemType=SMPP
SenderAddressOverride=Yes
Receive=Yes
ReceiveMMS=No
UseSSL=No
LongSMSAlt=Yes
ReceiveSingleConnection=Yes
UseDataSM=Yes
WDPAdaptation=Yes
UseTLV=Yes
ServiceType=USSD
BinaryDCS=0x0F
GSMPack=Yes
DefaultSMPPOptions=ussd_service_op=2
SourceTON=0
SourceNPI=0
DestTON=1
DestNPI=1
BindTON=0
BindNPI=0
MessagingMode=1
[SMPP - ussdServerIp2:7449]
RouteName=ussd
SMPPVersion=v3.4
UserName=-----
Password=*****
SystemType=SMPP
SenderAddressOverride=Yes
Receive=Yes
ReceiveMMS=No
UseSSL=No
ReceiveSingleConnection=Yes
LongSMSAlt=Yes
UseDataSM=Yes
WDPAdaptation=Yes
ServiceType=USSD
UseTLV=Yes
BinaryDCS=0x0F
GSMPack=Yes
DefaultSMPPOptions=ussd_service_op=2
SourceTON=0
SourceNPI=0
DestTON=1
DestNPI=1
BindTON=0
BindNPI=0
MessagingMode=1
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4979
Registered: 08-2008
Posted on Tuesday, August 05, 2014 - 08:32 pm:   

Hi Walid,

I think I see the problem.

The ussd_service_op in that 2nd response should probably be different.

The first message received has ussd_service_op=1

I assume the response uses the default configured setting ussd_service_op=2

The next received message has ussd_service_op=18

I assume that reply goes out with ussd_service_op=2 ... but should it? I am not that familiar with expected values here.

Another oddity ... I see in the log that the first inbound request comes from 10.11.1.5, but the reply goes out 10.11.1.4. Is that intended? I see you have the setting 2WayReplySameServer=Yes, but because the RouteName setting is t he same for both routes, the reply can go out either connection, which might be the problem.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 7
Registered: 07-2014
Posted on Tuesday, August 05, 2014 - 08:52 pm:   

Hi Des,

I change the route name for both routes (.4: RouteName=ussdServerIp1 et .5: RouteName=ussdServerIp2). but the problem still persist.

and to change dynamically the ussd_service_op, I need to use HTTP response. in this case, I have problem to introduce the 3 parameters below in the HTTP URL (they are not static):
- receipted_message_id
- dest_subaddress
- source_subaddress
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4980
Registered: 08-2008
Posted on Tuesday, August 05, 2014 - 09:01 pm:   

Hi Walid,

I read some more and I believe it is ok to always use ussd_service_op=2 (USSR request) in both cases.

I do notice one other thing.

I see this text in SMSDEBUG: Merci d'introduire votre mot de passe

But I never see it in SMPPDEBUG.LOG. So I don't think that reply is ever being sent. But I am not sure why.

Do you notice same in more recent logs?

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 8
Registered: 07-2014
Posted on Tuesday, August 05, 2014 - 09:30 pm:   

Hi Des,

Yes I notice same in more recent Log.

the problem there is no problem with the 2-way reply. and I don't understand why NowSMS doesn't reply with the proper message.

I attached here new SMPP and SMS Debug
application/octet-streamSMPP Debug
SMPPDEBUG.LOG (100.1 k)
application/octet-streamSMSDEBUG
SMSDEBUG.LOG (61.6 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4982
Registered: 08-2008
Posted on Tuesday, August 05, 2014 - 11:01 pm:   

Hi Walid,

I think I have a better idea now.

The reason I didn't see the "Merci d'introduire votre mot de passe" response is because 7-bit packed encoding is enabled for the connection under the SMPP Advanced Settings. That may be a source of some problems as this setting is normally used only with very old SMSCs.

The response is being processed and is being sent, it just was not in the encoding I expected (and possibly the USSD server is also not expecting).

HOWEVER, I do not think that is the main problem. There is a long delay in 2-way command processing and a long delay (30-40+ seconds) in sending out responses. Most likely these delays would cause timeouts for a USSD session. That is likely the main problem you are encountering. This suggests that there is a NowSMS license problem.

If this is a purchased license, you may have been sent a corrupt license file. Provide me with the details (Serial #, license count, company name) via email and I'll get it reissued. Send the details to nowsms@nowsms.com with Attention: Des in the subject line.

If this is a trial license, we have seen issues where unauthorized download sites post invalid copies of our software. For a trial version, the Serial # page should not display any serial numbers. If you see a serial #, but you're expecting a trial version, that is a problem. This can usually be fixed by highlighting the Serial # and clicking the Remove button ... then run the install again to repair the trial installation. (If you do have an invalid serial # that needs to be deleted, I would also strongly suggest a malware scan.)

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 9
Registered: 07-2014
Posted on Tuesday, August 05, 2014 - 11:19 pm:   

Hi Des,

problem was resolved!

Yes, it is a trial licence. and before purchasing the licence we need to test the platform. if ok, we will contact you to purchase our licence.

in the same, can you please send me your target price.

thanks.
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 10
Registered: 07-2014
Posted on Wednesday, August 06, 2014 - 12:44 pm:   

Hi Des,

thansk to your email. our sales department will contact you.

I have another problem of encoding I think. when I send "5882" to my platform, I receive in Log file :
2014-08-06 15:39:33,+25377789723,SMPP - 10.11.1.4:7449,Text="5ÆNù";SMSCRouteName=ussdServerIp1

please find attached here the SMPP and the SMS Debug
application/octet-streamSMPP Debug
SMPPDEBUG.LOG (1307.6 k)
application/octet-streamSMSDEBUG
SMSDEBUG.LOG (570.2 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4983
Registered: 08-2008
Posted on Wednesday, August 06, 2014 - 01:09 pm:   

Hi Walid,

The use of 7-bit encoding for short messages is rare in SMPP.

See where the GSMPack=Yes setting exists in SMSGW.INI? (This setting enables 7-bit encoding.) Add GSMPackReceive=Yes under each instance. This forces the receive decoding to 7-bit (instead of auto-determine).

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 11
Registered: 07-2014
Posted on Wednesday, August 06, 2014 - 03:32 pm:   

Hi Des,

Thank you very much for your support !

Now, it's work properly
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 12
Registered: 07-2014
Posted on Thursday, August 07, 2014 - 05:24 pm:   

Hi Des,

I need to change dynamically the ussd_service_op and I need to use HTTP response.

I have problem to introduce the 3 parameters below in the HTTP URL (they are not static):
- receipted_message_id
- dest_subaddress
- source_subaddress

can you please help me?

Thanks
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4984
Registered: 08-2008
Posted on Friday, August 08, 2014 - 12:33 pm:   

Hi Walid,

One tip...we have some old info on the web site about using an HTTP redirect response to generate the reply. This is still supported, but not recommended. Instead it is recommended that you generate an HTTP request to send a new message.

The parameters get added to the HTTP URL like this:

&SMPPOption_receipted_message_id=xxxxxxxx
&SMPPOption_dest_subaddress=aaaaaaaa
&SMPPOption_source_subaddress=bbbbbbbb
etc.

If you use an HTTP based 2-way command, you will see these parameters added to the URL command in the same format.

So you parse SMPPOption_dest_subaddress from the received URL and swap that value as the SMPPOption_source_subaddress in the reply message. Basically dest becomes source, and source becomes dest.

For SMPPOption_receipted_message_id, you take the received value and use the same variable name in the reply message.

What values of ussd_service_op (SMPPOption_ussd_service_op in URL) do you need to use, and under what conditions? I am wondering if there are small changes we could make to simplify this process.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 13
Registered: 07-2014
Posted on Sunday, August 10, 2014 - 05:15 pm:   

Hi Des,

how can I get the value of SMPPOption_source_subaddress when I receive this on SMSDEBUG :

18:21:37:350 [12] SMPPReceiveMessageCallback: inbound message: sender=+25377141376, recip=, pid=0, dcs=0, msgFlags=0, udh=, msg=*194#, extraParms=SMPPOption_receipted_message_id=20202A5655203C22595A2F43575350502B432 C512E3258512D43445E00; SMPPOption_source_subaddress=363338303130313030363631363237; SMPPOption_dest_subaddress=3235333737383930303037; SMPPOption_ussd_service_op=1; ServiceType=USS
18:21:37:351 [6] ThreadProcessInboundSMS: Processing 53E19A2C.in...
18:21:37:351 [6] GetProgramToExecute: Found 2-way command prefix match *
18:21:37:351 [6] GetProgramToExecute: Best match so far for 2-way command prefix *


Thanks
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4988
Registered: 08-2008
Posted on Monday, August 11, 2014 - 01:21 pm:   

Hi Walid,

If the 2-way command is HTTP based, &SMPPOption_source_subaddress=363338303130313030363631363237 will be automatically added to the 2-way URL.

Unfortunately, if you run as a local command, this is not accessible.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 14
Registered: 07-2014
Posted on Tuesday, August 19, 2014 - 12:13 am:   

Hi Des,

how can I get the receipted_message_id, dest_subaddress and the source_address from the MO? I want to use these parameters in the HTTP reply.

Thanks
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5000
Registered: 08-2008
Posted on Tuesday, August 19, 2014 - 08:00 pm:   

Hi Walid,

If the 2-way command is HTTP based, &SMPPOption_receipted_message_id=20202A5655203C22595A2F43575350502B432C512E32585 12D43445E00
&SMPPOption_source_subaddress=363338303130313030363631363237
&SMPPOption_dest_subaddress=3235333737383930303037
will be automatically added to the 2-way URL.

So you parse the URL parameters for these values.

Unfortunately, if you run as a local command, this is not accessible.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5001
Registered: 08-2008
Posted on Tuesday, August 19, 2014 - 08:01 pm:   

P.S. - As you seem to be having some difficulty...

What values of ussd_service_op (SMPPOption_ussd_service_op in URL) do you need to use, and under what conditions? I am wondering if there are small changes we could make to simplify this process.
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 15
Registered: 07-2014
Posted on Wednesday, August 20, 2014 - 12:17 am:   

Hi Des,

Yes, I have some difficulty.

when I try t use HTTP 2-way command, I can't collect these parameters to put them in my HTTP reply.

Now, I'm using 2-way local command and I specify the ussd_service_op=2 on the SMSGW.ini. But I need to change this value to 17 with the end of ussd scenario.

for example, when I compose *194#, I reply to the customer to send his ID, after I reply in order to send his password (in all this steps, the uss_service_op = 2 and its ok). after that I reply with information about the customer and I need to close ussd sesion. so I need to change the value of ussd_service_op to 17 when I send the last reply.

USSD Scenario


Please can you help me.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5002
Registered: 08-2008
Posted on Wednesday, August 20, 2014 - 05:08 pm:   

Hi Walid,

If you use a 2-way HTTP command do you get &SMPPOption_receipted_message_id=xxxxxxxx &SMPPOption_ussd_service_op=x ... but NOT the subaddress parameters?

If that is the case, add these entries to the [SMPPOptions] setting of SMSGW.INI:

source_subaddress=202,HexString
dest_subaddress=203,HexString

If you are not seeing any of these parameters, and the 2-way command starts with http://, then I would like to see SMSDEBUG.LOG for a transaction.

If you are not using a HTTP based 2-way command, I am discussing potential ideas with our engineering team.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 16
Registered: 07-2014
Posted on Monday, August 25, 2014 - 06:48 am:   

Hi Des,

Thanks to your reply.

please find attached here the SMSDEBUG File Log

application/octet-streamSMS DEBUG
SMSDEBUG.LOG (772.0 k)



it's required to close session (to use diffenernt value of _ussd_service_p) to buy the licence also. (th operator require the closure of session otherwise it stops service).


please help us
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5008
Registered: 08-2008
Posted on Monday, August 25, 2014 - 03:18 pm:   

Hi Walid,

I think the only way to get this to work is to convert to using a 2-way based HTTP command.

What I mean by this is that you convert the Java program to run as a servlet on a web server. Instead of parsing command line parameters, you parse HTTP GET URL parameters (uri.getQueryParameter), then to submit the reply, make a new HTTP connection with all of the URL parameters to send a message that contains the desired SMPP options.

If the 2-way command is just a local command, there is no good way to pass these extra options. But with an HTTP based command, NowSMS adds additional GET/query parameters.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 17
Registered: 07-2014
Posted on Monday, August 25, 2014 - 05:04 pm:   

please have you an example?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5010
Registered: 08-2008
Posted on Monday, August 25, 2014 - 06:04 pm:   

For servlets in general, here's a good tutorial: http://tutorials.jenkov.com/java-servlets/overview.html

Basically the servlet runs under a web server, such as Tomcat or Jetty.

Your Java code implements an HttpServlet method. The HTTP request gets routed to the servlet as an HttpServletRequest. An example parsing parameters is here: http://tutorials.jenkov.com/java-servlets/httprequest.html

Overall, it is a lot easier to parse these HTTP parameters with getParameter than it is to parse command line parameters. But the difficult part is that you need to setup the web server that runs the servlet.

--
Des
NowSMS Support
Walid Boudhir
New member
Username: Walidboudhir

Post Number: 18
Registered: 07-2014
Posted on Monday, August 25, 2014 - 09:46 pm:   

Hi Des,

it's working fine now.

thank you very much :)

Login Login / Register Logout Logout Search Last 30 Days Topics Topics