USSD Response

USSD Response SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through September 26, 2009 » USSD Response « Previous || Next »
Author Message
Naser Gharachi
New member
Username: Gharachi

Post Number: 1
Registered: 06-2009
Posted on Wednesday, July 29, 2009 - 03:51 am:   

Hi,

I have created a connection to our SMSC by SMPP. I receive USSD commands by NowSMS but when NowSMS send response, the sender receives a SMS. Command to exexute is cmd.exe /c echo TEST.

Thank you
Naser
application/octet-streamSMSIN-20090729.LOG
SMSIN-20090729.LOG (0.1 k)
application/octet-streamSMSOUT-20090729.LOG
SMSOUT-20090729.LOG (0.2 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1083
Registered: 08-2008
Posted on Wednesday, July 29, 2009 - 02:50 pm:   

Hi Naser,

You need to talk to your provider about what options you need to set in order to generate a USSD reply on their system.

You most likely need to configure "USSD" as the service_type for the SMPP connection. This is an advanced setting that you need to configure by manually editing the SMSGW.INI file. Under the [SMPP - server:port] section for this SMSC connection, add ServiceType=USSD

I'd also suggest, under the [SMSGW] header of SMSGW.INI, adding: 2WayReplySameServer=Yes

If you have multiple SMSC connections, this second setting will ensure that your replies get sent back through the correct SMSC connection.

If this doesn't get you anywhere, enable the SMSDEBUG.LOG in NowSMS.

Send another USSD request in to your command. Post the resulting SMSDEBUG.LOG and SMPPDEBUG.LOG. We can get a better idea of what options and settings may be used by your provider by looking at those log files.

--
Des
NowSMS Support
Naser Gharachi
New member
Username: Gharachi

Post Number: 2
Registered: 06-2009
Posted on Thursday, July 30, 2009 - 11:58 am:   

Hi Des,
I have implemented what are recommended but I have same problem still. I send the result to our provider and yoy can see their response in the bellow. Please advice me to solve the problem.
Best regards,
Naser

Dear Naser,
Please explain your exact problem.
I see in the log this traces Below:

USSD entry frame
80 33053 +989347691000 +432140000020864 +989347691001 +989347691000 +989347697290 15 *272#
Sent to the client smpp
13 1014 2615 +0 272 +989347697290 0 0 0 0 0 9280 0 0 80 33053 272#
smpp client Ack
3 1014 0 0 0 006013 20090730_074533_195533: 6 163888 192.168.0.2 +989347697290 +272:SMPP;USSD_TKC_272;60001ce357924c80 0 0 0 2 0 0 0 0 TEST\r\n
smpp client sending SMS
6 163888 192.168.0.2 +989347697290 +272:SMPP;USSD_TKC_272;60001ce357924c80 0 0 0 2 0 0 0 0 TEST\r\n
SRI
12 1015 +989347691001 +0 +989347691000 +0 1079 +989347697290 +989347691001 10 2 0
SRI_Ack
16 1015 0 0 0 0 +432140000020864 +989347690000 +0 0 -1
14 163888 ;0;0;0;0;KFZO(Telecommunication Kish Company);Iran;GSM;1;2;0;1;0;0;
FWD_SM
27 1016 +989347691001 +989347691001 +989347690000 1079 +432140000020864 943584d9f417a4f6 +272 +989347697290 0 0 0 0 255 90700301033380 45 2 0 06D4E294DA5000
FWD_SM Ack
3 1016 0 0 0 0 +0 +0

It seem ok just loss the frame 81 USSD Ack.
Best Regards Yves
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1094
Registered: 08-2008
Posted on Thursday, July 30, 2009 - 12:13 pm:   

Hi Naser,

Can I see the SMSDEBUG.LOG and SMPPDEBUG.LOG files generated by our software in this situation. That will help me to understand better, because I do not understand the full context/format of the above log traces.

I would suggest that you e-mail them to nowsms@nowsms.com with "Attention: Des" in the subject line.

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

Post Number: 1095
Registered: 08-2008
Posted on Thursday, July 30, 2009 - 02:55 pm:   

Hi Naser,

I'm certain that the SMPP server wants some other attribute to be returned so that it knows that the message should be delivered as a USSD response.

Some USSD servers just keep the session open until a timeout expires, and assume any response back to the original sender must be a USSD reply.

Others require more tracking information.

From other inquiries, I've seen the its_session_info parameter referenced frequently. It wasn't originally designed for USSD, but its use seems to have been coopted by some USSD center manufacturers.

Here's how to configure NowSMS to support the its_session_info parameter, and to automatically include it in 2-way replies.

Edit SMSGW.INI.

Create a new section like this:

[SMPPOptions]
its_session_info=1383,Integer,2


(If an [SMPPOptions] section already exists in SMSGW.INI, add the above to that section.)

Under the [SMSGW] header add:

2WayReplyCopySMPPOptions=its_session_info

The above settings will configure NowSMS to support the its_session_info parameter, and when replying to a message via the 2-way command facility, it will pass back that parameter in the response.

That might be enough to get you working. But it's just a guess ... it is possible that your USSD center uses different SMPP attributes.

If this doesn't work, I'd like to see an SMPPDEBUG.LOG to see what parameters are present in the received message.

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

Post Number: 1105
Registered: 08-2008
Posted on Friday, July 31, 2009 - 04:54 pm:   

A general follow-up after an e-mail exchange of more information.

Every USSD system is a little different.

First, I'm going to talk about what I'd call the "de facto" standard for how many USSD SMPP interfaces are implemented.

In general, it is quite difficult to implement a USSD service using simple 2-way SMS commands. It is possible, but it depends on how the USSD system is implemented.

Most USSD systems use an SMPP service_type of "USSD". To set this value in NowSMS, edit SMSGW.INI, and under the [SMPP - host:port] section for the SMPP connection, add ServiceType=USSD.

Many also use the ussd_service_op and its_session_info optional parameters.

The ussd_service_op parameter is used as it is described in the SMPP documentation.

The its_session_info parameter is used to contain a session/transaction id so that the USSD server can maintain the session state of an active USSD session.

To enable NowSMS support for these parameters, edit SMSGW.INI, and create a new section like this:

[SMPPOptions]
ussd_service_op=501,Integer,1
its_session_info=1383,Integer,2

(If an [SMPPOptions] section already exists in SMSGW.INI, add the above to that section.)

When these parameters are used by a USSD system, it is generally required that the its_session_info be returned back in any replies.

When simple 2-way SMS is used (e.g., "command returns response text"), NowSMS can be configured to automatically include this parameter in the response by editing SMSGW.INI, and under the [SMSGW] header adding:

2WayReplyCopySMPPOptions=its_session_info

When the ussd_service_op parameter is used, things are more complicated. The mobile originated message has one ussd_service_op value, and you use a different ussd_service_op value in the reply based upon what type of response you wish to send. (Some USSD systems may assume that if this is not present, it is a simple response that should be delivered and then the session closed.)

For most applications, they will always reply back with the same ussd_service_op value for all messages. In that case, it is possible to edit SMSGW.INI, and under the [SMPP - host:port] section that defines the SMPP connection to the USSD gateway, you can add DefaultSMPPOptions=ussd_service_op=x ... where x is the value that you want to set for this parameter. NowSMS will then set that parameter value for all messages sent via that SMPP connection.

If you need to set different values for this parameter, or you need to otherwise process either of these parameters in a 2-way command, HTTP based 2-way commands must be used.

NowSMS will automatically append "&SMPPOption_ussd_service_op=x" to the 2-way command URL when the parameter is defined in the [SMPPOptions] section of SMSGW.INI *and* the parameter is present in a received message.

To specify any of these parameters in a reply, the 2-way command must use the "redirect response" technique described at http://www.nowsms.com/support/bulletins/tb-nowsms-003.htm. "&SMPPOption_ussd_service_op=x" can be appended to the URL built to submit the message to NowSMS to specify a value for this option.

That's all well and good, but none of this information applies to the USSD SMPP interface that Naser is using.

The system that Naser is using uses an SMPP destination_port value of 9280 to indicate that the message is USSD.

This can be accomplished in NowSMS with the following settings:

Replace the existing [SMPPOptions] section of SMSGW.INI with this:

[SMPPOptions]
destination_port=20B,Integer,2

Then, in the [SMPP - server:port] section for this server, add the following:

DefaultSMPPOptions=destination_port=9280

The above settings will cause every message that you send via this connection to have the SMPP optional parameter destination_port set to 9280, which is how this particular server implements USSD.

Instead of using the ussd_service_op and its_session_info parameters, this information is recorded in the text of the message.

To reply back to the message, the text of the reply must start with an operation type value, followed by the transaction id, followed by the reply text.

Looking at his logs, he would see an inbound message that looked like this:

80 34419 272#

To reply back properly to this message, operation type value 81 needed to be used. To reply back with "This is my response", it was necessary to put the following in the 2-way command reply text:

81 34419 This is my response

Naser may have some other comments/implementation details to share.

Unfortunately, every USSD system is a little different when it comes to their implementation of the SMPP interface. The general rules that I outlined above may apply for some systems, but it is often necessary to check the vendor's documentation to better understand their implementation.

Naser was able to create a simple 2-way command to process the prefix "80", as follows:


quote:

For testing the USSD, I did add the following line to smsgw.ini:

ReceiveSMSCommand1=80 c:\USSDtest.bat @@FULLSMS@@ Yes

the batch file included following lines:
@echo off
@echo 81 %2 Welcome





--
Des
NowSMS Support

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