[sr-dev] [kamailio/kamailio] presence: incorrect dialog state for multiple dialogs xml body (#1427)
Vasiliy Ganchev
notifications at github.com
Mon Feb 5 11:50:49 CET 2018
### 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 at 10.100.1.24:5064" local-uri="sip:251 at 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 at 10.100.1.24" call-id="4070150262 at 10.100.1.24" local-tag="as7c372911" remote-tag="3861741811" remote-uri="sip:252 at 10.100.1.24:5064" local-uri="sip:254 at 10.100.1.85:6050" direction="initiator">
<note>On the phone</note>
<remote>
<identity display="user252">sip:252 at 10.100.1.85</identity>
<target uri="sip:252 at 10.100.1.85">
</target>
</remote>
<local>
<identity display="user254">sip:254 at 10.100.1.85</identity>
<target uri="sip:254 at 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 at 10.100.1.24" call-id="4070150262 at 10.100.1.24" local-tag="as7c372911" remote-tag="3861741811" remote-uri="sip:252 at 10.100.1.24:5064" local-uri="sip:254 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180205/6c2e7802/attachment.html>
More information about the sr-dev
mailing list