Hello, I have a problem with BLF (Busy Lamp Fields, i.e. dialog events) on Yealink T41S: the key status (green or blinking red) freezes when calling a user to which we SUBSCRIBEd. It freezes until the subscription expires. Using sngrep, I was able to see that some NOTIFYs get a timeout (they are sent 3 times) because the phone doesn't reply (200 OK). These NOTIFY seem to have in common the fact that the caller is the SUBSCRIBEd Yealink user. Example on NOTIFY body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="full" entity="sip:callee@sip.com"> <dialog id=&quot;5_2630032430(a)11.202.138.255&quot; call-id=" 5_2630032430(a)11.202.138.255&quot; direction="recipient"> <state>confirmed</state> <remote> <identity>sip:caller@sip.com:5060</identity> <target uri="sip:caller@11.202.138.255:5060"/> </remote> <local> <identity>sip:callee@sip.com:5060</identity> <target uri="sip:callee@sip.com:5060"/> </local> </dialog> </dialog-info> caller(a)sip.com subscribed to callee(a)sip.com and then called it. I wasn't able to find a solution with the current implementation, for example presence_dialoginfo/force_single_dialog = 1 doesn't help. I come with a setting modparam("presence", "dont_notify_subscribed_caller", 1) that, if enabled, doesn't NOTIFY a subscriber if this one is the caller itself. It does this by validating remote and local elements in the xml body of the NOTIFY message against the message target. Is there a better solution? The technical questions: 1. I verify the sender in the function notify(..) by analyzing the dialog's event xml body. Is there a more direct method, not passing by this xml? modparam("pua_dialoginfo", "include_localremote", 0) - might be missing, but it's not relevant 2. I would have preferred a flag-like solution: but how to flag (refuse) a NOTIFY message that doesn't even pass by the configuration script? For example, I could activate that flag for a SUBSCRIBE coming from "User-Agent: Yealink SIP-T41S". 3. I am using xml_utils.h, so libser_cds, libser_presence, but is this alright? I had to modify their Makefiles for the build to succeed, this gets new dependencies in presence.so ... 4. I verify only that dialog-info/remote & local/identity is not the one of the recipient (the subscriber) and, if so, I stop the notification ... Because the message could contain multiple dialogs, this technique is not enough: removing parts of the dialog is necessary. Thank you, Liviu