Description

The issue started with this improvement:
839cf89
(it works fine for single dialog bodies, but make a mess with multiple-dialog bodies)

Troubleshooting

Test scheme, preconditions:

SIP server: kamailio + Asterisk
3 SIP phones. UA-A, UA-B, UA-C

Kamailio is configured with presence+presence_dialoginfo modules.
Asterisk sends PUBLISHes regarding changes of dialog's state, kamailio process it (handle_publish), and send NOTIFIYs to all subscribed endpoints

Bug description (the issue is considered from the point of view of UA-B's state):

UA-A calls to UA-B => Asterisk send PUBLISHes (dialog UA-B1), UA-B (states on-the Trying -> Proceeding -> Confirmed)
UA-B makes attended transfer to UA-C (call answered) => Asterisk send PUBLISHes with complex XML (2 dialogs state in a body. UA-B1(Confirmed) and new UA-B2 (Confirmed))
UA-B completes the transfer, as a result, Asterisk sends (bodies from this 2 PUBLISHes are below, in the SIP traffic section):
1. PUBLISH with multiple dialog body (UA-B1 - terminated, UA-B2 - confirmed) => processed OK
2. PUBLISH with single dialog body (UA-B2 - terminated.) => Bug is here
  so now:

presentity.c:1084 checks is_dialog_terminated // check is dialog terminated for event: dialog
  presentity.c:549 calls get_dialog_state 
       //   make a db query with the previous state (that query returnes: (UA-B1 - terminated, UA-B2 - confirmed))
       //   loop through result returned from DB, call parse_dialog_state_from_body
         presentity.c:307  - at this function:
                    ... 
                    node = xmlNodeGetChildByName(node, "dialog"); // return part of xml with 2 dialogs
                    ...
                    childNode = xmlNodeGetChildByName(node, "state"); // return state of the first! dialog in a list, not the current dialog
                    ...
due to obtained state is "terminated", if(is_dialog_terminated(presentity))  returnes TRUE
and subsequent code sends silently 200OK.

Result:

those subscribed to dialog state of UA-B, do not recieve NOTIFY with a valid state (BLFs remain "lighting")

Attempts of workaround:

I tried to go to "send_412" logic when is_dialog_terminated (TRUE).
But in the subsequent PUBLISH (state=terminated) Asterisk does not insert "call-id, to-tag, from-tag" parameters, and endpoint fails to recognize which dialog is terminated, and BLF remains to light.

SIP Traffic

not SIP, but only relevant part of XML bodies.
Multiple dialogs body, this one is last to succeed (look at the state of first dialog)

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="36" state="full" entity="252">
<dialog id="3bf1a5de53394e394f7b0241067faccf" call-id="3bf1a5de53394e394f7b0241067faccf" local-tag="as27f0e6f0" remote-tag="1349583034" remote-uri="sip:252@10.100.1.24:5064" local-uri="sip:251@127.0.0.1:6050" direction="recipient">
<note>Ready</note>
<remote>
<identity>252</identity>
<target uri="252">
</target>
</remote>
<local>
<identity>251</identity>
<target uri="251"/>
</local>
<state>terminated</state>
</dialog>
<dialog id="4070150262@10.100.1.24" call-id="4070150262@10.100.1.24" local-tag="as7c372911" remote-tag="3861741811" remote-uri="sip:252@10.100.1.24:5064" local-uri="sip:254@10.100.1.85:6050" direction="initiator">
<note>On the phone</note>
<remote>
<identity display="user252">sip:252@10.100.1.85</identity>
<target uri="sip:252@10.100.1.85">
</target>
</remote>
<local>
<identity display="user254">sip:254@10.100.1.85</identity>
<target uri="sip:254@10.100.1.85"/>
</local>
<state>confirmed</state>
</dialog>
</dialog-info>

Next PUBLISH is with single dialog, and its update is ignored (as incorrect state evaluated)

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="37" state="full" entity="252">
<dialog id="4070150262@10.100.1.24" call-id="4070150262@10.100.1.24" local-tag="as7c372911" remote-tag="3861741811" remote-uri="sip:252@10.100.1.24:5064" local-uri="sip:254@10.100.1.85:6050" direction="initiator">
<note>Ready</note>
<remote>
<identity>252</identity>
<target uri="252">
</target>
</remote>
<local>
<identity>254</identity>
<target uri="254"/>
</local>
<state reason="local-bye">terminated</state>
</dialog>
</dialog-info>

Possible Solutions

Sorry for the long story, but for now I need your advice, with the logic for the fix (I already tried to start to fix, but get stuck with the logical concept).
My current insight is quite cumbersome:

before is_dialog_terminated => get an array of dialogs call-ids from the body of current PUBLISH. Give it as input parameter for is_dialog_terminated
while processing get_dialog_state/parse_dialog_state_from_body = try to match state of matched dialogs
in some way try to update not complete body in a DB, but make some "partial" update. (update only those dialogs whose old state is NOT "terminated")

Thanks in advance for your advice. If the issue unclear from my description, please ask for details.

Additional Information

Kamailio Version - output of kamailio -v

kamailio -v
version: kamailio 5.0.3 (i386/linux)
flags: STATS: Off, EXTRA_DEBUG, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 11:27:38 Jan 30 2018 with gcc 4.3.2

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.