Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Send and Receive SMS

  1. #11
    Join Date
    Jul 2008
    Posts
    268

    Default

    Hi tttelcom,

    I think this functionality was added as part of 2.2.6 through Asterisk Manager events. Here is an excerpt from the readme:


    --------------- Issues resolved in PADS 2.2.6 -----------------------

    8425: GSM module resends SMS indefinitely

    - A maximum number of retries has been added to limit the re-sending attempts.
    The maximum number of retries can be configured using the "sms_send_retry" configuration
    key. This default value is 5.
    Note: The SMSSuccess and SMSError Asterisk Manager events have been added to report
    success or failure to send the SMS.

  2. #12
    tttelecom Guest

    Default

    I understand the send confirmation, which is working fine. However, this is not what I meant. What I need is confirmation that the recipient has received the SMS. This is a network service where the provider replies with a (free) confirmation SMS. For (critical) alerting purposes I really need to know whether the SMS has reached it's final destination.

    For example, if I send an SMS to a mobile phone that cannot be reached (e.g. is switched off) I will still get a send confirmation from the provider. However, a delivery notification/SMS will only be sent by the provider when the end point mobile phone has switchd back on (i.e. is reachable) and has actually received the SMS. Using this SMS I can match it to an SMS sent, so that the status can be properly updated in our alerting system.

    This is a (provider) network service that any mobile phone can toggle on/off. See also: http://en.wikipedia.org/wiki/SMS#Message_size

    Message delivery is "best effort", so there are no guarantees that a message will actually be delivered to its recipient, but delay or complete loss of a message is uncommon. Users may request delivery reports to confirm that messages reach the intended recipients, either via the SMS settings of most modern phones, or by prefixing each message with *0# or *N#.eee


    The prefixing solution is not the one desired. The prefix is different for each provider and will also reduce the number of available characters for the message.

    I also found the following. Apparently this needs to be set in de SMS-SUBMIT PDU:

    "GSM 03.40 is the specification that gives you details on this. You can get it from www.etsi.org. GSM 07.05 concerns AT commands and SMS messaging. From GSM03.40:

    9.2.3.5 TP-Status-Report-Request (TP-SRR)
    The TP-Status-Report-Request is a 1-bit field, located within bit no. 5 of the first octet of SMS-SUBMIT
    and SMS-COMMAND, and to be given the following values:
    Bit no. 5: 0 A status report is not requested
    1 A status report is requested"
    I hope this clarifies my initial question a bit better.

  3. #13
    Join Date
    Jul 2008
    Posts
    268

    Default

    Hi tttelecom,

    Yes, I now understand better. If you contact Pika they might be able to provide you some documentation for the GSM radio. But from what I gather from the GSM specification the command of interest is 'AT+CSMP' which sets SMS text mode parameters.

    To set the TP-Status-Report-Request field the following command at the Asterisk CLI should work.

    gsm send at 1 AT+CSMP=49,167,0,0

    And from my understanding this should result in a SMS message being received indicating successful delivery of the message. Unfortunately I have yet to get this to work myself
    Last edited by mrecoskie; 04-12-11 at 07:32 AM. Reason: spelling correction in command

  4. #14
    Join Date
    Jul 2008
    Posts
    268

    Default

    Additionally to the CSMP command the following line should be added at the end of the '/etc/asterisk/gsm-init-file' file and a restart done:

    at+cnmi=2,1,0,1,0 ok 0 10

    This will enable CDS responses.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •