Dear Jesri,

It can be the wrong DATA_CODING to .NET encoding mapping.
https://docs.inetlab.com/smpp/v2.9/arti ... oding.html

I need to check the SUBMIT_SM PDU you received from the client. Please send the Wireshark file to the support@ .

Hi,

What value has data_coding field in the DELIVER_SM PDU?
I would use the same data_coding in the SUBMIT_SM PDU and set appropriate .NET Encoding in the EncodingMapper for the client.

https://docs.inetlab.com/smpp/v2.9/arti ... oding.html

The outbind was incomplete in the Inetlab.SMPP library. The version 2.9.18 has additional classes for this feature: - SmppOutbindClient class that can establish SMPP session with ESME using Outbind command. - SmppOutbindServerClient class, that passed down to the evClientOutBind event in the SmppSer...

Hi,

What kind of proxy are you going to use? SOCKS5?

Hello ojukwu24

For now SmppClient represents one SMPP session with SMS provider. Therefore if you need to establish multiple sessions with one or many providers you need to create the same number of SmppClient instances and attach event handler method to all instances.

It depends on the USSD service implementation on the provider side. I would ask the provider support how it should be sent. When you have an answer, I can help you to complete this with Inetlab.SMPP library. The answer can be also that the message text is limited to 140 octets. You can try to send t...

Hi

The date and time format is defined in the SMPP protocol specification.

Hello André, It should be normal. User data header for concatenation takes 6 octets in the short_message field. Possible one of the character in your text takes two octets, therefore 153 instead of 154. Or you use 16-bit reference number. Could you post an example for this case? Which code do you us...

Could you please test this case with the recent version of the library. Some issues with connect/disconnect are already fixed. See ChangeLog

What library version are you using?

Which error do you mean? "Remote side has dropped connection." ? This error means that the provider didn't accept the TCP/IP connection from your IP. It can be a firewall issue. Why do you use local IP address 127.0.0.1:8887 to connect to SMPP provider? Consider connection recovery build-in feature ...

Hi,

Did you send only one SubmitSm in this test? It seems the SMSC returns different MessageId in SubmitSmResp and in delivery receipt.

Could you create wireshark file for this test and send to support@ ?

Hi,

I hope the article Send Messages helps you.

This issue is fixed in the version 1.0.0-beta-2580.

Please note: The method Submit in the MM7Client class is now Task-based.

Thank you for reporting this bug. I'll try to fix it as soon as possible.