7 Apr
2022
7 Apr
'22
6:18 a.m.
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="5_2630032430(a)11.202.138.255" call-id="
5_2630032430(a)11.202.138.255" 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