If Subscription refresh occurred between when the batched notification
was scheduled and the serialized notification was to be sent,
then new schedule notification task would never be added.
There are 2 threads:
thread #1. ast_sip_subscription_notify is called,
if notification_batch_interval then call schedule_notification.
1.1. The schedule_notification checks notify_sched_id > -1
not true, then
send_scheduled_notify = 1
notify_sched_id =
ast_sched_add(sched, sub_tree->notification_batch_interval, sched_cb....
1.2. The sched_cb pushes task serialized_send_notify to serializer
and returns 0 which means no reschedule.
1.3. The serialized_send_notify checks send_scheduled_notify if it's false
the just returns. BUT notify_sched_id is still set, so no more ast_sched_add.
thread #2. pubsub_on_rx_refresh is called
2.1 it pushes serialized_pubsub_on_refresh_timeout to serializer
2.2. The serialized_pubsub_on_refresh_timeout calls pubsub_on_refresh_timeout
which calls send_notify
2.3. The send_notify set send_scheduled_notify = 0;
The serialized_send_notify should always unset notify_sched_id.
ASTERISK-29904 #close
Change-Id: Ifc50c00b213c396509e10326a1ed89d8cf8c7875
pjsip_dlg_inc_lock(dlg);
+ sub_tree->notify_sched_id = -1;
+
/* It's possible that between when the notification was scheduled
* and now a new SUBSCRIBE arrived requiring full state to be
* sent out in an immediate NOTIFY. It's also possible that we're
? "SUBSCRIPTION_TERMINATED" : "SUBSCRIPTION_STATE_CHANGED",
"Resource: %s", sub_tree->root->resource);
- sub_tree->notify_sched_id = -1;
pjsip_dlg_dec_lock(dlg);
ao2_cleanup(sub_tree);
return 0;