[Home]

Summary:ASTERISK-13591: [patch] SIPNotify dialplan application
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-02-17 04:04:30.000-0600Date Closed:2011-06-07 14:02:36
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dialplan_sip_notify.diff2.txt
Description:It's come up before, regarding having a dialplan application to do SIPNotify, similar to the cli command 'sip notify'

Avoids the awful way it's currently done in dialplan
exten => 2345,n,System(/usr/sbin/asterisk -rx "sip notify grandstream-idle-screen-refresh GXP0009")

Only supports one local peer as required for our purpose, which was to remotely request a refresh of Idle Screen on a Grandstream GXP series phone with latest firmware 1.1.6.46.

syntax is as simple as
exten => 2345,n,SIPNotify(grandstream-idle-screen-refresh,GXP0009)

code is copied from chan_sip.c:sip_cli_notify with appropriate mods.


****** ADDITIONAL INFORMATION ******

file sip_notify.conf
....
[grandstream-idle-screen-refresh]
Event=>x-gs-screen
Content-Length=>0

[grandstream-gxp-check-cfg]
Event=>check-sync
Content-Length=>0
....
Comments:By: Alec Davis (alecdavis) 2009-02-17 04:45:15.000-0600

please remove dialplan_sip_notify.diff.txt

uploaded dialplan_sip_notify.diff2.txt

cleanup, and further testing revealed that if 2nd argument wasn't set, asterisk would segfault.

console output:
  -- Executing [2345@default:1] SIPNotify("Console/dsp", "grandstream-gxp-check-cfg,GXP0009") in new stack
   -- Sending NOTIFY of type 'grandstream-gxp-check-cfg' to 'GXP0009'
   -- Executing [2345@default:2] Dial("Console/dsp", "DAHDI/32,20") in new stack
By: Alec Davis (alecdavis) 2009-02-18 03:27:17.000-0600

Anybody able to help out, the DialPlan needs to know whether the SIP Notify was accepted or not?
Then after that I can take appropriate dialplan action, right now the SIPNotify is sent blind.

If the phone is active (not idle) it will return a 480 response, Temporarily Unavailable.

example console output:
   -- Executing [2345@trusted:1] SIPNotify("DAHDI/33-1", "grandstream-idle-screen-refresh,GXP0009") in new stack
   -- Sent NOTIFY of type 'grandstream-idle-screen-refresh' to 'GXP0009'
   -- Executing [2345@trusted:2] Dial("DAHDI/33-1", "DAHDI/32,20") in new stack
   -- Called 32
   -- DAHDI/32-1 is ringing
   -- Got SIP response 480 "Temporarily Unavailable" back from 192.168.124.51
By: Alec Davis (alecdavis) 2009-02-18 14:18:28.000-0600

Snuffy and others have suggested that SIP Notify become a dialplan application
refer http://bugs.digium.com/bug_view_page.php?bug_id=12962

This is the beginning of it.

Compared code with manager_notify, and it's closer to that, should have looked first. So between sip_cli_notify and manager_notify and now this app, there isn't too much to go wrong.

Tested and in use.
By: Alec Davis (alecdavis) 2009-03-06 06:14:54.000-0600

I've noticed in chan_sip there are other dialplan apps, that have comments to the effect;
/todo, should wait for a response, so we know whether we fail or not.

refer to the following code above 'transmit_refer' in chan_sip.c

I'm now in the same position, from what I could find, no routines wait around and check the response after the send_request.
By: Alec Davis (alecdavis) 2009-03-16 15:40:33

Anybody able to help with the ability to wait for a '200 OK' or other response?
Do I need to wait for SIP transaction support?
By: Alec Davis (alecdavis) 2009-04-29 04:08:01

In the SIP section of the next release notes we can have:
* Added SIPnotify DIALPLAN command, for sending arbitrary SIP notify commands.

Although I've asked some questions regarding acknoledgement that the command was received OK, the submitted patch works. It doesn't know wheter the send was successful, just as the CLI command 'sip notify' and the SIPnotify AMI command don't know either.
By: Leif Madsen (lmadsen) 2009-09-18 09:14:43

I'm wondering if using a dialplan function actually makes more sense? I'd see using it like:

exten => s,n,Set(RES=${SIP_NOTIFY(...)})

Where ${RES} then contains the result of the NOTIFY.

However, I've worked around this in the dialplan using the MinivmNotify() application to set and unset the NOTIFY messages for an end point. Perhaps you can look to see how it is done there?
By: Leif Madsen (lmadsen) 2010-03-24 13:15:51

Pinging this issue. Do we think a function is better than an application here? I like the idea generally though!
By: Alec Davis (alecdavis) 2010-03-24 15:42:07

If we can detect whether the SIP device actually received and accepted or rejected then yes a function would work.

When I last looked at this and noted in ~101301, the only method was to send the notify, and hope that it got to the device, rejected or not...
By: Leif Madsen (lmadsen) 2010-03-24 20:05:50

Ahhhh ok that makes sense. If we're not going to expect a response from the end point, then ya, an application makes the most sense.

Maybe you should put it on reviewboard if you think it's pretty much ready to go?
By: David Chappell (chappell) 2010-04-13 15:33:44

I have two suggestions:

* Can we make the dialplan app SIPNotify() work more like the manager command SIPNotify and less like the CLI command sip notify?  Specifically: Use name=value pairs to specify the content of the message rather than selecting a preprepared message from sip_notify.conf.  (That keeps the whole thing together in the dialplan.)

* Allow us to omit the peer name in order to send the NOTIFY message to the phone associated with the channel.  (And make it a NoOp if the channel type is not SIP.)
By: Leif Madsen (lmadsen) 2010-04-15 12:12:57

Set to feedback for reporter.
By: Paul Belanger (pabelanger) 2010-06-25 09:01:26

ping! Cleaning up tracker, what is the status?
By: David Chappell (chappell) 2010-07-19 09:59:00

I would be willing to prepare a patch implementing the suggestions which I made on the 13th of April.
By: Alec Davis (alecdavis) 2010-07-19 15:44:33

We ended up executing the sipnotify from a dialplan script.<pre>
dialplan: where ARG2 is the sip device
exten => s,n,System(/usr/sbin/refresh ${ARG2})

astrid:/usr/sbin# cat refresh
# !/bin/bash
ampuser=$1
sip_refresh(){
      sleep 1
      for x in $ampuser
      do
              /usr/sbin/asterisk -rx "sip notify grandstream-idle-screen-refresh $x"
      done
}
sip_refresh &
echo $ampuser $x</pre>
By: Paul Belanger (pabelanger) 2010-09-04 14:12:43

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines