### Description
The issue started with this improvement:
https://github.com/kamailio/kamailio/commit/839cf89b02f8817156487a960ff62013e3cde530
(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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1427
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to