### Description
The issue started with this improvement:
https://github.com/kamailio/kamailio/commit/839cf89b02f8817156487a960ff6201…
(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(a)10.100.1.24"
call-id="4070150262(a)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(a)10.100.1.24"
call-id="4070150262(a)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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1427