I have started again on a fresh branch to investigate presence monitoring of conference extensions, and I think I have discovered another problem with the way that NOTIFYs containing dialog events are formulated. RFC4235 says: "state: This attribute indicates whether the document contains the full dialog information, or whether it contains only information on those dialogs that have changed since the previous document (partial)." and "Notifications do not normally contain full state; rather, they only indicate the state of the dialog(s) whose state has changed. The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a NOTIFY that contains no dialog elements. These NOTIFYs contain the complete view of dialog state." But what I see the code doing is *never* sending a complete (full) list of dialogs, even if there are more than one, and marking all the presence event related NOTIFY events as "full" even though by the definition above, they are all "partial". One observable effect is if you are monitoring a conference extension. The light will begin to flash when one person joins the conference, and goes solid when another joins, but then goes out when one person leaves, even though others are still in. This is because the NOTIFY is sent with status "full" but only contains the one "terminated" dialog, and none of the others which are still "confirmed". I'm not sure yet what is the best way to solve this. I think that sofia_presence_sub_callback is always generating "partial" updates, because it is always considering only the most recent event. I think that the sofia_presence_resub callback will have to generate one event, containing all the rows retrieved from the query, rather than what it does now (which is send a SWITCH_EVENT_PRESENCE_IN for each row, which is handled by the sofia_presence_sub_callback and thus results in a bunch of what are really "partial" NOTIFYs, instead of one "full" NOTIFY). Does this make sense? Carolyn