[asterisk-bugs] [JIRA] (ASTERISK-18331) app_sms failure

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan closed ASTERISK-18331.
----------------------------------

    Resolution: Fixed

> app_sms failure
> ---------------
>
>                 Key: ASTERISK-18331
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18331
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_sms
>    Affects Versions: 1.8.5.0
>         Environment: Fedora 15 i386, B200P ISDN BRI, Dadhi.
>            Reporter: David Woodhouse
>         Attachments: asterisk-fix-sms.patch, pbx-handle-link.patch
>
>
> There are three issues with app_sms.
> Firstly, the 'flags' field in the sms_exec() function is not initialised, causing the wrong protocol to be selected in some cases because the OPTION_TWO flag is erroneously set. This is described at https://issues.asterisk.org/jira/browse/ASTERISK-15361?focusedCommentId=160885#comment-160885
> Secondly, smsq seems to work by creating a call file and then hard-linking it into the spool directory /var/spool/asterisk/outgoing. This appears to be correct behaviour according to the documentation. However, Asterisk's use of inotify has *broken* this, in favour of broken clients which do the wrong thing. Asterisk sees that hard link as a IN_CREATE event, and it assumes a broken client and *waits* for a subsequent IN_CLOSE_WRITE event on the same file, indicating that the file has been closed after being opened for write. Such an event never comes, of course. The smsq tool just unlinks its original temporary filename for the same file.
> I fix that second issue by using rename() instead of link() + unlink() in smsq.c, but really I'm disappointed that Asterisk penalised a valid client in order to pander to broken clients. If you're going to watch for IN_CLOSE_WRITE that's cute, but you should notice it and *refuse* to run the call file, with a clear explanation of why. And that way the broken clients can be fixed.
> The third issue is as described in ASTERISK-15426 — app_sms does not behave correctly when the far end stops sending data and the call isn't terminated for some reason. Just putting the trailing \n on the log message is a good start, but my patch also make app_sms handle this situation gracefully if it's already sent the REL message to instruct the other end to terminate the call. If we've sent a REL message and then the peer stops sending data, *don't* just bitch about it over and over again in the logs and keep the channel open. Just hang up our end too.
> With these changes, app_sms is working properly again for me with British Telecom.



--
This message was sent by Atlassian JIRA
(v6.2#6252)