From b81ed5a88560889482419fbcf79ea918d7d5ebef Mon Sep 17 00:00:00 2001 From: Stefan Schmidt Date: Tue, 13 Dec 2011 15:20:33 +0000 Subject: [PATCH] Fix possible misshandling of an incoming SIP response as a peer poke response. 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 ........ Merged revisions 348048 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@348056 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- channels/chan_sip.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/channels/chan_sip.c b/channels/chan_sip.c index 56466c694d..246ef8d932 100644 --- a/channels/chan_sip.c +++ b/channels/chan_sip.c @@ -21084,8 +21084,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 @@ -21359,7 +21365,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" */