Fix improper usage of scheduler exposed by 5c713fdf18

When 5c713fdf18 was merged, it allowed for scheduled items to have an ID of
'0' returned. While this was valid per the documentation for the API, it was
apparently never returned previously. As a result, several users of the
scheduler API viewed the result as being invalid, causing them to reschedule
already scheduled items or otherwise fail in interesting ways.

This patch corrects the users such that they view '0' as valid, and a returned
ID of -1 as being invalid.

Note that the failing HEP RTCP tests now pass with this patch. These tests
failed due to a duplicate scheduling of the RTCP transmissions.

ASTERISK-25449 #close

Change-Id: I019a9aa8b6997584f66876331675981ac9e07e39
This commit is contained in:
Matt Jordan
2015-10-05 21:34:41 -05:00
parent 89dec7675d
commit 8cb614fe20
3 changed files with 17 additions and 17 deletions

View File

@@ -4322,7 +4322,7 @@ void sip_scheddestroy(struct sip_pvt *p, int ms)
}
p->autokillid = ast_sched_add(sched, ms, __sip_autodestruct, dialog_ref(p, "setting ref as passing into ast_sched_add for __sip_autodestruct"));
if (p->stimer && p->stimer->st_active == TRUE && p->stimer->st_schedid > 0) {
if (p->stimer && p->stimer->st_active == TRUE && p->stimer->st_schedid > -1) {
stop_session_timer(p);
}
}
@@ -22743,7 +22743,7 @@ static void check_pendings(struct sip_pvt *p)
sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
} else if (ast_test_flag(&p->flags[0], SIP_NEEDREINVITE)) {
/* if we can't REINVITE, hold it for later */
if (p->pendinginvite || p->invitestate == INV_CALLING || p->invitestate == INV_PROCEEDING || p->invitestate == INV_EARLY_MEDIA || p->waitid > 0) {
if (p->pendinginvite || p->invitestate == INV_CALLING || p->invitestate == INV_PROCEEDING || p->invitestate == INV_EARLY_MEDIA || p->waitid > -1) {
ast_debug(2, "NOT Sending pending reinvite (yet) on '%s'\n", p->callid);
} else {
ast_debug(2, "Sending pending reinvite on '%s'\n", p->callid);