Summary:ASTERISK-09602: [patch] Authentication support for SIP NOTIFY requests
Reporter:Igor Goncharovsky (igorg)Labels:
Date Opened:2007-06-06 04:54:23Date Closed:2008-04-22 11:55:32
Versions:Frequency of
Environment:Attachments:( 0) 012908-Patched-chan_sip.c-zktech.txt
( 1) 012908-SipDebug-zktech.txt
( 2) sip_debug.txt
( 3) sip_notify_auth-74477-7.patch
( 4) sip_notify_auth-81326-8.patch
( 5) sip_notify_auth-87498-9.patch
( 6) sipnotify.log
( 7) sipnotify-110578-v13.patch
( 8) sipnotify-113980-v14.patch
( 9) sipnotify-14-102626-v12.patch
(10) sipnotify-14-110474-v13.patch
(11) sipnotify-14-89312-v11.patch
(12) sipnotify2.log
(13) sipnotify-89312-10.patch
(14) sipnotify-v12.log
(15) sipnotify-v12-2.log
Description:This issue is the same to issue 4151? close 2 years ago. I have develop my patch, and find same issue.

Currently console command "sip notify" send notify packet and destroy SIP dialog without delay. But sip device can answer with 401 message to ask auth. For example Linksys phones and ATA.

Patch and sip debug of authorized notify dialog attached.


There several question, related to this patch:
1) Is the normal to use same tag in From header for outgoing second NOTIFY?
2) I have not tested ye situation if device have no done any answer on our NOTIFY. We can have here hang channel.
3) RFC say that NOTIFY mandatory must have Subscription-State header. Is this good way to hardcode this header to chan_sip, or write in sip_notify.conf
4) Function transmit_sip header used only in sip_transfer and include 3 strings of code, can it be deleted?

Comments:By: Igor Goncharovsky (igorg) 2007-06-06 05:01:25

Oh, I find bug in my patch after posting this.

PS. This patch include 2 grammatical mistakes in debug message, this, i think, can be commited before this issue solve.

By: Olle Johansson (oej) 2007-06-08 02:27:25

Well, the whole SIP notify is a bad piece of code and it's about time to clean that up. I'll look at your patch in a week or so, have some pressing bugs to fix first.

By: Igor Goncharovsky (igorg) 2007-06-14 01:40:40

New patch uploaded, that fix miss of last header in notify.

By: Igor Goncharovsky (igorg) 2007-06-14 05:07:46

About my questions in first message:

1) After reading RFC and look for some other call scenarios, i find that will be better if notify with auth use other tag.
2) Seems that it is not related to this feature
3) I'll put this header into code, for always RFC compatible NOTIFY messages.
4) I'll delete this function, there is no reason to have so function.

By: Igor Goncharovsky (igorg) 2007-06-19 22:06:08

Patch updated, waiting for review from oej.

By: Igor Goncharovsky (igorg) 2007-07-11 05:20:19

I have reduce additional variables number and move it to begin of function. All previos patches can be deleted. Also I must note that this issue is continue of Issue 0004151, it can be added to relationships.

By: Igor Goncharovsky (igorg) 2007-08-28 23:39:12

Patch updated for latest trunk, also fixed bugs.

By: Jared Smith (jsmith) 2007-08-29 13:46:16


Can you please take a look at this latest patch?  This is something I've been wanting for quite some time.

By: Igor Goncharovsky (igorg) 2007-10-30 00:53:30

Patch updated for latest trunk....

By: Bryant Zimmerman (zktech) 2007-11-13 14:42:03.000-0600

What is that status of this bug/patch.. Will the patch work with the Grandstream phones I am getting a 401 response from the phones when I send the sip notify. Grandstream states that the authorization hash must be sent with the sip notify or be provided with challenged. I do not see any indication that asterisk is replying when challenged.   How would I apply this patch? and Might it help?


By: Igor Goncharovsky (igorg) 2007-11-13 21:16:13.000-0600

Yes, it might be useful also with Grandstream. You can patch current ttrunk it by following commands:

cd asterisk
patch -p1 <../sip_notify_auth-87498-9.patch

By: Igor Goncharovsky (igorg) 2007-11-15 05:00:54.000-0600

zktech, also please write here about result of you testing this patch with Grandstream.

By: Bryant Zimmerman (zktech) 2007-11-15 09:56:43.000-0600

I tried to apply the patch to the 1.4.13 rev and did not get it to work.. Can someone give me a link or some instructions to get the trunk version. Also is the trunk verson safe to run on more than a test box or is it likly to break a lot of things.  I will report back on my findings as soon as I can get the correct version and patch working. Also if the patch works how soon would it be before it makes it into a relase version?

I am a windows guy so please be explicite with any directions. I have only been on linux for about a year.


By: Igor Goncharovsky (igorg) 2007-11-15 10:12:40.000-0600

You can get trunk asterisk as described here:
I think this code is a bugfix, therefore I can also prepare patch for 1.4 brach, when it'll realy redy to merge.

By: Bryant Zimmerman (zktech) 2007-11-15 12:03:14.000-0600

I got these errors when patching and building the trunk version are these normal?  The trunk version does compile correctly if I do not apply the patch. But it is not completeing when I try to comile it after applying the patch. What could be causing these errors.

zkt-col-ast001:/usr/src/asterisk # patch -p1 <sip_notify_auth-87498-9.patch
patching file channels/chan_sip.c
Hunk 4 succeeded at 3647 (offset 8 lines).
Hunk 5 succeeded at 7761 (offset 41 lines).
Hunk 6 succeeded at 7775 (offset 41 lines).
Hunk 7 succeeded at 7792 with fuzz 2 (offset 41 lines).
Hunk 8 succeeded at 7851 (offset 47 lines).
Hunk 9 succeeded at 8081 (offset 56 lines).
Hunk 10 succeeded at 12609 (offset 124 lines).
Hunk 11 FAILED at 12622.
Hunk 12 succeeded at 13526 (offset 139 lines).
Hunk 13 succeeded at 13926 (offset 145 lines).
1 out of 13 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
patching file configs/sip_notify.conf.sample
zkt-col-ast001:/usr/src/asterisk #

Errors on Build:
 [CC] chan_sip.c -> chan_sip.o
chan_sip.c: In function âtransmit_inviteâ:
chan_sip.c:7798: warning: passing argument 1 of âast_unescape_semicolonâ discards qualifiers from pointer target type
chan_sip.c: In function âsip_notifyâ:
chan_sip.c:12639: warning: implicit declaration of function âtransmit_sip_requestâ
chan_sip.c:12612: warning: unused variable ânewvarâ
chan_sip.c: In function âhandle_response_notifyâ:
chan_sip.c:13533: warning: implicit declaration of function âast_string_field_freeâ
chan_sip.c:13533: error: âtheirtagâ undeclared (first use in this function)
chan_sip.c:13533: error: (Each undeclared identifier is reported only once
chan_sip.c:13533: error: for each function it appears in.)
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2
zkt-col-ast001:/usr/src/asterisk #

By: Igor Goncharovsky (igorg) 2007-11-15 22:23:28.000-0600

This one should work with current trunk

By: Bryant Zimmerman (zktech) 2007-11-16 20:35:45.000-0600


The trunk version is acting funny it won't run my dial plan scripts correctly. I have been able to test the patch with the GXP2020 and GXP2000 and it looks good so far.. It is not working with the Handy Tone 286 or 386. I am having the guys at Grandstream test this to find out what is different. On the 386 I get an authorization failed and a 415 respone on the 286. I will post as soon as I know more. Thanks

By: Igor Goncharovsky (igorg) 2007-11-19 10:10:42.000-0600

You can also attach debug with Handy Tone 286 and 386 or send it direct to me at igi-go[at]ya[dot]ru. I'll also want look on this.

By: marioja (marioja) 2008-01-25 09:00:33.000-0600

Will this be added to the 1.4 branch? If so when?  Thanks.

By: Bryant Zimmerman (zktech) 2008-01-25 09:40:55.000-0600

I have now tested this patch with the current public release firmware for the Grandstream GXP 2000, GXP 2020, GXP 2010. It also appears that the current engineering versions for the HT286 and HT386 are working with this as well. Grandstream has assured me that they are serious in their support of the sip-notify on their entire product line..

When can we get this patch into the release branch. I want to run it in production but have not figured out how to make it work on the branch versions. The trunk versions have some issues I can not live with in production.  Thanks You

I am very anxiously awaiting your replay.

By: Igor Goncharovsky (igorg) 2008-01-25 11:03:09.000-0600

No, it can't included in 1.4, but I can prepare patch for it. Probably on Monday.

By: Bryant Zimmerman (zktech) 2008-01-25 19:28:43.000-0600

Getting a patch would be great. Will that patch support any of the 1.4.X release from here on out, or will we have to keep getting a new patch for every release of 1.4.X? I am currently on 1.4.13 and testing 1.4.17 for production.

Also what will it take to get it into the main branch? Will it ever be eligable for the 1.4 branch or is there some thing holding it back. Anything we can help with?

Thanks for all of your hard work

By: Igor Goncharovsky (igorg) 2008-01-28 07:06:04.000-0600

zktech: Ok, here patch, that compile with 1.4. But there is no warranty that it works. I have no time now to test it. Also I think, that sending NOTIFY without auth is a bug, and this patch have no new functionality. Then it can be included into 1.4.

Anyway, waiting for comments from oej to move forward.

By: Bryant Zimmerman (zktech) 2008-01-28 10:06:23.000-0600

I will test the patch as best I can. I have just a couple of questions. That will help me wrap my head around this issue.

1. Is there a specific folder name/location that the source must be in for the patch to run correctly? I used /usr/src/asterisk/trunk with the previous releases.

2. You said "I think, that sending NOTIFY without auth is a bug, and this patch have no new functionality.".
It is my understanding that sending notify with out wating for a response reqests is a bug in astrisk. According to the Grandstream guys. They receive a NOTIFY request and challange with an auth request. If the auth response is valid then they proceed with the notify. Is this what your statment is saying, and your patch provides the fix to allow asterisk to wait for the clients response and to respond to the auth requests correctly?

Thank you for your hard work.

By: Igor Goncharovsky (igorg) 2008-01-29 04:14:45.000-0600

1. No.
2. Yes, that is what I mean.

By: Bryant Zimmerman (zktech) 2008-01-29 13:45:09.000-0600

I rolled the patch onto our production test server running version 1.4.17 Branch release.. I tried it on a phone that had worked with the previous patch and the trunk version and I got the following message.  Any ideas what I should do next. The phone did not reboot as before. I also tried a ATA and got the same message.

[Jan 29 14:50:30] WARNING[3085]: chan_sip.c:12712 handle_response: Got authentication request (401) on unknown NOTIFY to '<sip:ZKT-2003@;transport=udp>;tag=5aae189a0d04800b'

This is the section I am running from the sip_notify.conf

zkt-col-ast001*CLI>sip notify gs-reboot ZKT-2003


By: marioja (marioja) 2008-01-30 07:29:31.000-0600

I tried to patch the 1.4 branch but when I ran the patch, I got a message that the patch could not find the files so I had to specify the two files in order to patch.  Then I get the negative result documented in the sipnotify.log.  Can either of you tell me what is the command to get the 1.4 branch and what is the command to patch?  Thanks.

By: marioja (marioja) 2008-01-30 07:55:58.000-0600

You should skip sipnotify.log and look at sipnotify2.log.  I think (am not sure) that I may have applied the patch better.  Still had to specify the file names when running the patch file.  But it still does not work.  I have turned sip debugging and core debug and verbose to level 10

By: marioja (marioja) 2008-01-30 08:01:21.000-0600

Igore, I don't think that sending a notify without the auth is a bug. I further think that only registers and invite are required to be challenged by a 401. I think requiring a notify to be challenged by a 401 is not in the SIP protocol per say. I could be wrong though and I am not sure you exactly meant the opposite of what I just said.  At any rate, my two cents worth.

By: Bryant Zimmerman (zktech) 2008-01-30 10:54:20.000-0600

As per marioja post I too had to manually specify the files locations durring patching. This was no big deal. It however is different than what I had to do when patching the trunk version.

I have done some more testing that I hope will help figure out why the patch is not working with the branch release. I have attached the file 012908-SipDebug-zktech.txt file. This file contains the sip debug from Asterisk for a call to the sip notify. It also contains the syslog responses from the device that I am sending the sip notify to. Based on what I am understanding. It looks as if the Auth information being sent back to the phone is not correct. This was not the case in when I tested back in November with the trunk version.

I am also attaching the patched version of my chan_sip.c code file so you can see if the patch is taking correctly.

Thanks for your hard work.

By: Bryant Zimmerman (zktech) 2008-01-30 14:01:41.000-0600

IgorG I have now completed packet snif testing and It is very obvious that that the patch is not either installing correctly or working correctly on the branch version. I found the patched November trunk version on a test sever and ran it and it worked. I am not sure what I should look for to see if the patch is actually fully installing. I do not see any errors when I patch the files, but I may just be missing somthing. The attached 012908-Patched-chan_sip.c-zktech.txt is a copy of my code that is compiling after runing the patch.


By: marioja (marioja) 2008-01-30 14:09:23.000-0600

Bryant, your test results are different than mine. In my case, asterisk never sends a new SIP NOTIFY upon receiving the 401 whereas in your case it does.  I have attempted to use the trunk patched version and my asterisk would core dump. maybe you can email me your trunk patched executable to bug9896.10.poema@spamgourmet.com. If you can also send me your 1.4 branch one too that would be useful.  Thanks Mario

By: Bryant Zimmerman (zktech) 2008-01-30 14:35:34.000-0600

marioja The sip debug looks like it is sending the response to the 401 request but my packet snif test show that it is not being received by the phone. I am anticipating that it is not actually being sent. Here is a synopsis of my packet traces on the phone.

1.4.17 Branch/Nov Trunk No Patch
Request Notify xxx
Status: 401 Unauthorized

1.4.17 Branch with Patch
Request Notify xxx
Status: 401 Unauthorized

Nov Trunk with Patch
Request Notify xxx
Status: 401 Unauthorized
Status: 200 OK

Mario  I will send you my Nov trunk version and my patched 1.4.17 version. My e-mail address is xxxxxxx. I have tar ziped them and have posted it on our ftp server. I will e-mail you access instructions

By: Bryant Zimmerman (zktech) 2008-01-31 16:20:05.000-0600

IgorG When might you get a chance to look at this again? Is there any additonal info that would help you? Big Thanks!

marioja Did you get my e-mail with the ftp info in it?

By: Igor Goncharovsky (igorg) 2008-02-01 00:08:41.000-0600

I'll install 1.4 branch on my test server as soon as I'll back to work (most likely on Tuesday).

By: Marc Andre (mandre) 2008-02-04 09:02:36.000-0600

IgorG, thanks for you work.
I tried your 1.4 patch with Linksys SPA-2102 and resync event. I get a 401 (www-authentication) response instead of a 407 (proxy authentication) response. This is currently not handled in your patch.
I could get it running by changing:
- handle_response_notify() similar to handle_response_refer(). Use the correct parameters to do_proxy_auth (auth and auth2 variables).
- In handle_response(), case 401 add
   "else if (sipmethod == SIP_NOTIFY)"
   "handle_response_notify(p, resp, rest, req, seqno);"
 similar to case 407.

Sorry I couldn't create a patch for you as I haven't signed the agreement yet. Do you agree with my modifications? Will you add them to your patch? If necessary I will add my patch as soon as possible.

By: Igor Goncharovsky (igorg) 2008-02-04 21:52:15.000-0600

Yes, this is right fix for 1.4. I still ill, if you can place here new patch do it, without waiting for me.

By: Marc Andre (mandre) 2008-02-06 05:08:59.000-0600

I added Patch sipnotify_14-102626-v12.patch, which is a modification of the v11 patch with the changes that I mentioned for 401 authentication. The patch works against the current 1.4-branch.

By: Bryant Zimmerman (zktech) 2008-02-06 11:42:09.000-0600

I moved the patch into production on 1.4.17.

Here is my current status on Grandstream testing
GXP2000 FW 1.5.15 Working
GXP2020 FW 1.5.15 Working
HT 502 FW Working
HT 386 Not working on Current Firmware or Test FW
HT 286 FW Does not always register after sip notify reboot.
HT 286 FW prior to Not working at all
GXV 3000 Pending Testing

I will update this post as I have more info.
The patch is looking good. You guys Rock

Big Big Thanks

By: marioja (marioja) 2008-02-06 16:53:05.000-0600

I just applied patch sipnotify_14-102626-v12.patch to the 1.4 branch and it did not work.  See sipnotify.v12.log I just attached for details.  I get the usual 401 but no response.  The version reported for the patched asterisk executable is:

Asterisk SVN-branch-1.4-r102725M built by root @ trixbox on a i686 running Linux on 2008-02-06 20:18:31 UTC

By: marioja (marioja) 2008-02-06 16:59:11.000-0600

Here is how I create the patch

svn update (it brings it to revision 102802)
ftp main/asterisk executable to box running 1.4 version of asterisk.
stop current asterisk program
start using new executable
run test with ip debug on peer

Am I doing something wrong?

By: Michiel van Baak (mvanbaak) 2008-02-06 17:05:41.000-0600

yes. the main asterisk binary is not the only thing involved.
You should also at least upgrade the /usr/lib/asterisk/modules/ directory

Best to create a package or something like that (debian has checkinstall for that)

By: marioja (marioja) 2008-02-08 08:25:46.000-0600

See the logfile sipnotify-v12-2.log I just attached. This time I copied the chan_sip.so to the modules directory and I got asterisk to respond but look at the double authentication headers.  They have different formats also.  It replied twice to the 401 but it did not work still.  I even noticed that the first NOTIFY (before the 401) even has an authentication header.

By: Marc Andre (mandre) 2008-02-12 02:44:11.000-0600

marioja can you please post your sip.conf extract of that peer?

IgorG, I think the problem is at the the earliest lines in transmit_request_with_auth() where a authentication is already being sent if !ast_strlen_zero(p->realm)

By: Bryant Zimmerman (zktech) 2008-03-07 19:08:32.000-0600

I have had the v12 patch in production on 1.4.17 since 02-06-08 with out any issues all seems to be working well.  Does anyone know what the state of this is now? Should the v12.path work on 1.4.18?  Is this somthing that will soon be close enough to roll into the normal turnk releases as well as the 1.6 betas.  

A big thanks to all who are working on this.

By: Igor Goncharovsky (igorg) 2008-03-08 00:02:00.000-0600

Ask Digium developers and oej in IRC. This issue is in the oej's list for review, but I think it is long and Olle have no time. Also U think it is not hard to add this patch bot in 1.4, 1.6 and trunk.

No thanks, thank you for testing and reporting.

By: Igor Goncharovsky (igorg) 2008-03-23 22:24:44

Patches updated to latest trunk and 1.4 branch per request. Also current patches, I think, have two issues:

1) Pointed by marioja situation with 401 Unauthorized
2) If __sip_destroy called while construction of NOTIFY request and p->notify_headers deleted before all fields added to request. I'll check this when have more time.

By: Alex Sinitsyn (xelas) 2008-03-24 07:15:36

Last patch:  sipnotify-110578-v13.patch tested on Asterisk SVN-branch-1.6.0-r110579M with Linksys SPA941/SPA942 and work perfectly.
Tested with events: reboot_now, restart_now, resync, report.

By: Bryant Zimmerman (zktech) 2008-03-24 08:01:58

What was the change from the v12 patch to the v13 patch? Other than adding 1.6 support.


By: Igor Goncharovsky (igorg) 2008-03-24 09:07:58

Update to current code, that changed and one chunk of patch failed.

By: Olle Johansson (oej) 2008-03-26 05:51:31

handle_response_notify propably needs to be more generic and handle all responses to NOTIFY.

By: Igor Goncharovsky (igorg) 2008-03-26 10:37:28

Ok. Thank you oej, I'll try to make this function more general. I think we have outgoing NOTIFY in two place:
1. Notify of voicemail messages volume
2. Notify of device state

That's all?

By: Olle Johansson (oej) 2008-03-26 10:42:39

...and transfers (sipfrag)

By: Igor Goncharovsky (igorg) 2008-04-10 05:17:37

Ok, I back. Upload new patch with more generic handle_response_notify. If need comments on change than I am ready.

By: Bryant Zimmerman (zktech) 2008-04-10 12:04:16

I am running the v12 patch in production. What has changed on the v14 patch. Should I expect it to work any differntly or is it just carring the changes to all the correct areas? Can I deploy the v14 into the same copy of the code I did the v12 or will I need to roll back to the base code before deployment. Let me know and I will get v14 tested and into production ASAP.

By: Igor Goncharovsky (igorg) 2008-04-10 22:53:40

v14 is only for trunk, I'll prepare 1.4 version if it needs to commit. There are no functional changes only make some more general as of oej request.

Detail list of changes:
1) More general handle_response_notify
2) sip_notify renamed to sip_cli_notify as it less confusing
3) Separate transmit_notify_custom function
4) Less changes to transmit_invite function (Allow, Supported and Date should sent in authenticated NOTIFY).

Also transmit_invite also one function that have confusing name, isn't it, oej?

PS. All files before sipnotify-v12.log can be deleted from issue.

By: Bryant Zimmerman (zktech) 2008-04-11 00:07:36

I am not running the trunk version. I am running the branch version. So what would it take for me to get the v14 patch to run on the branch version of 1.4.19?

I have tryed to apply it against 1.4.19 and I got 7 Hunks Failing out of 21 on the chan_sip.c file.

Any input is apperciated.

By: Bryant Zimmerman (zktech) 2008-04-18 10:35:18

Any update on how or when I could get this patch working on the 1.4.19 Branch Release? When might this make it out of the patch stage?  Version 12 is working on the 1.4.17 Branch release. I have to have the SIP Notify working so I can reboot ATA's and Phones. For now I am stuck at 1.4.17 unitl I can get a working version for the current Branch.

Big thanks for all the hard work. I will await responses.

By: Digium Subversion (svnbot) 2008-04-22 10:48:46

Repository: asterisk
Revision: 114529

U   trunk/channels/chan_sip.c
U   trunk/configs/sip_notify.conf.sample

r114529 | file | 2008-04-22 10:48:45 -0500 (Tue, 22 Apr 2008) | 6 lines

Add support for authenticating on a NOTIFY request. This is useful for phones that require it when sending them a special packet to get them to do something (such as reload their configuration).
(closes issue ASTERISK-9602)
Reported by: IgorG
     sipnotify-113980-v14.patch uploaded by IgorG (license 20)



By: Digium Subversion (svnbot) 2008-04-22 10:49:17

Repository: asterisk
Revision: 114530

_U  branches/1.6.0/

r114530 | file | 2008-04-22 10:49:16 -0500 (Tue, 22 Apr 2008) | 13 lines

Blocked revisions 114529 via svnmerge

r114529 | file | 2008-04-22 12:54:06 -0300 (Tue, 22 Apr 2008) | 6 lines

Add support for authenticating on a NOTIFY request. This is useful for phones that require it when sending them a special packet to get them to do something (such as reload their configuration).
(closes issue ASTERISK-9602)
Reported by: IgorG
     sipnotify-113980-v14.patch uploaded by IgorG (license 20)




By: Digium Subversion (svnbot) 2008-04-22 11:55:32

Repository: asterisk
Revision: 114535

_U  team/seanbright/resolve-shadow-warnings/
U   team/seanbright/resolve-shadow-warnings/CHANGES
U   team/seanbright/resolve-shadow-warnings/apps/app_jack.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_sip.c
U   team/seanbright/resolve-shadow-warnings/configs/sip_notify.conf.sample
U   team/seanbright/resolve-shadow-warnings/main/manager.c
U   team/seanbright/resolve-shadow-warnings/main/utils.c

r114535 | seanbright | 2008-04-22 11:55:30 -0500 (Tue, 22 Apr 2008) | 73 lines

Merged revisions 114520,114523,114527,114529,114533 via svnmerge from

r114520 | murf | 2008-04-22 10:38:46 -0400 (Tue, 22 Apr 2008) | 15 lines

Hopefully, this will resolve the issues that russellb had with this log_show_lock().
I gathered the code that filled the string, and put it in a different func which
I cryptically call "append_lock_information()".
Now, both log_show_lock(), and handle_show_locks() both call this code to do
the work. Tested, seems to work fine.
Also, log_show_lock was modified to use the ast_str stuff, along with checking
for successful ast_str creation, and freeing the ast_str obj when finished.
A break was inserted to terminate the search for the lock; we should never
see it twice.

An example usage in chan_sip.c was created as a comment, for instructional

r114523 | russell | 2008-04-22 11:20:53 -0400 (Tue, 22 Apr 2008) | 20 lines

Blocked revisions 114522 via svnmerge

r114522 | russell | 2008-04-22 10:20:37 -0500 (Tue, 22 Apr 2008) | 13 lines

Merge changes from team/russell/issue_9520

These changes make sure that the reference count for sip_peer objects properly
reflects the fact that the peer is sitting in the scheduler for a scheduled
callback for qualifying peers or for expiring registrations.  Without this, it
was possible for these callbacks to happen at the same time that the peer was
being destroyed.  This was especially likely to happen with realtime peers, and
for people making use of the realtime prune CLI command.

(closes issue ASTERISK-9243)
Reported by: kryptolus
Committed patch by me


r114527 | russell | 2008-04-22 11:46:01 -0400 (Tue, 22 Apr 2008) | 8 lines

Correct action_ping() and action_events() with regards to Manager 1.1
documentation.  Also, fix a bug in xml_translate().

(closes issue ASTERISK-11124)
Reported by: ys
     trunk_manager.c.diff uploaded by ys (license 281)

r114529 | file | 2008-04-22 11:54:06 -0400 (Tue, 22 Apr 2008) | 6 lines

Add support for authenticating on a NOTIFY request. This is useful for phones that require it when sending them a special packet to get them to do something (such as reload their configuration).
(closes issue ASTERISK-9602)
Reported by: IgorG
     sipnotify-113980-v14.patch uploaded by IgorG (license 20)

r114533 | russell | 2008-04-22 12:47:00 -0400 (Tue, 22 Apr 2008) | 4 lines

Add a c() option for the Jack() application and JACK_HOOK() funciton for supplying
a custom client name.  Using the channel name is still the default.  This was done
at the request of Jared Smith.