kenmirrors/asterisk
1
0
Fork 0
mirror of https://github.com/asterisk/asterisk.git synced 2025-10-31 18:55:19 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix possible misshandling of an incoming SIP response as a peer poke response.

Browse Source 
Also make sure peer has even qualify enabled when handle a peer poke response.

(closes issue ASTERISK-18940)
Reported by: Vitaliy
Tested by: Vitaliy and UnixDev

Review: https://reviewboard.asterisk.org/r/1620
Reviewed by: David Vossel



git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Stefan Schmidt
2011-12-13 15:16:50 +00:00
parent 607398d450
commit 9d53f3352b
1 changed files with 8 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
channels/chan_sip.c
View File

@@ -20572,8 +20572,14 @@ static void handle_response_peerpoke(struct sip_pvt *p, int resp, struct sip_req
* -1 means did not respond, 0 means unknown,
* 1..maxms is a valid response, >maxms means late response.
*/
if (pingtime < 1) /* zero = unknown, so round up to 1 */
if (pingtime < 1) { /* zero = unknown, so round up to 1 */
pingtime = 1;
}
if (!peer->maxms) { /* this should never happens */
pvt_set_needdestroy(p, "got OPTIONS response but qualify is not enabled");
return;
}
/* Now determine new state and whether it has changed.
* Use some helper variables to simplify the writing
@@ -20799,7 +20805,7 @@ static void handle_response(struct sip_pvt *p, int resp, const char *rest, struc
return;
}
if (p->relatedpeer && p->method == SIP_OPTIONS) {
if (p->relatedpeer && sipmethod == SIP_OPTIONS) {
/* We don't really care what the response is, just that it replied back.
Well, as long as it's not a 100 response... since we might
need to hang around for something more "definitive" */