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

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348048 65c4cc65-6c06-0410-ace0-fbb531ad65f3

diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index 71490a44fd1461609619fc4ccf8a75ffa5c4a347..ff084225eb4ed5cedade8bcfe88665aca5d9b3cf 100644 (file)
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -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" */