[SR-Users] UPDATE --- Can "presence" module handle publish reqs with several dialog entries? + Problem SOLUTION
Klaus Feichtinger
klaus.lists at inode.at
Wed May 7 13:15:23 CEST 2014
Hi Daniel,
I think we´ve found the reason, why this problem occurs!
The problem is caused in the "agregate_xmls" function in file "notify_body.c" of
the "presence_dialoginfo" module:
/* loop over all bodies and create the aggregated body */
for(i=0; i<j; i++)
{
/* LM_DBG("[n]=%d, [i]=%d, [j]=%d xml_array[i]=%p\n", n, i, j,
xml_array[j] ); */
p_root= xmlDocGetRootElement(xml_array[i]);
if(p_root ==NULL) {
LM_ERR("while geting the xml_tree root element\n");
goto error;
}
if (p_root->children) {
for (node = p_root->children; node; node = node->next) {
if (node->type == XML_ELEMENT_NODE) {
LM_DBG("node type: Element, name: %s\n", node->name);
/* we do not copy the node, but unlink it and then add it ot
the new node
* this destroys the original document but we do not need it
anyway.
* using "copy" instead of "unlink" would also copy the
namespace which
* would then be declared redundant (libxml unfortunately
can not remove
* namespaces)
*/
if (!force_single_dialog || (j==1)) {
xmlUnlinkNode(node);
if(xmlAddChild(root_node, node)== NULL) {
LM_ERR("while adding child\n");
goto error;
}
It seems to be not the best idea to "unlink" the XML node (=
"xmlUnlinkNode(node);"), as then no "node->next" is available any more.
Therefore, this loop will _always_ stop after one dialog entry and ignore any
additional one!
But we "solved" the problem in this way that the loop will not directly use
"node->next", but a variable, which is set within the loop. It looks like this:
xmlNodePtr next_node = NULL;
[...]
if (p_root->children) {
for (node = p_root->children; node; node = next_node) {
next_node = node->next;
if (node->type == XML_ELEMENT_NODE) {
[...]
This solution has been tested with 2 and 3 dialog entries in a single PUBLISH
request and it is working fine. We should discuss if this is a problem that
should be solved generally or if it is a "private" problem in our use case.
What do you mean?
regards,
Klaus
P.S. debug output (excerpt) of the "adapted" src code of release 4.1.3:
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:744]: get_p_notify_body(): Event requires aggregation
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:75]: dlginfo_agg_nbody(): [pres_user]=116001
[pres_domain]= 10.16.48.44, [n]=1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:127]: agregate_xmls(): [pres_user]=116001
[pres_domain]= 10.16.48.44, [n]=1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:146]: agregate_xmls(): parsing XML body:
[n]=1, [i]=0, [j]=0 xml_array[j]=0x9311820
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:167]: agregate_xmls(): number of bodies in
total [n]=1, number of useful bodies [j]=1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:211]: agregate_xmls(): [n]=1, [i]=0, [j]=1
xml_array[i]=0xc0c0c0c0
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:222]: agregate_xmls(): node type: Element,
name: dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:222]: agregate_xmls(): node type: Element,
name: dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:222]: agregate_xmls(): node type: Element,
name: dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:81]: dlginfo_agg_nbody(): [n_body]=0xb7ab5274
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:84]: dlginfo_agg_nbody(): [*n_body]=<?xml
version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="00000000000" state="full" entity="sip:116001 at 10.16.48.44">#012 <dialog
id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA at 172.31.60.13"
call-id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA at 172.31.60.13"
direction="recipient">#012<state>terminated</state>#012<remote>#012<identity>sip:1101015004 at 172.31.60.13</identity>#012<target
uri="sip:1101015004 at 172.31.60.13"/>#012</remote>#012<local>#012<identity>sip:117103 at 172.31.60.87</identity>#012<target
uri="sip:117103 at 172.31.60.87"/>#012</local>#012</dialog>#012 <dialog
id="1041054395-29684904-1398759995534 at 172.31.60.53"
call-id="1041054395-29684904-1398759995534 at 172.31.60.53"
direction="initiator">#012<state>confirmed</state>#012<remote>#012<identity>sip:117101 at 172.31.60.87</identity>#012<target
uri="sip:117101 at 172.31.60.87"/>#012</remote>#012<local>#012<identity>sip:117103 at 172.31.60.87</identity>#012<target
uri="sip:117103 at 172.31.60.87"/>#012</local>#012</dialog>#012 <dialog
id="2081054457-54683129-1398759736821 at 172.31.60.54"
call-id="2081054457-54683129-1398759736821 at 172.31.60.54"
direction="recipient">#012<state>alerting</state>#012<remote>#012<identity>sip:1101015005 at 172.31.60.87</identity>#012<target
uri="sip:1101015005 at 172.31.60.87"/>#012</remote>#012<local>#012<identity>sip:117103 at 172.31.60.87</identity>#012<target
uri="sip:117103 at 172.31.60.87"/>#012</local>#012</dialog>#012</dialog-info>#012
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:1564]: send_notify_request(): headers:#012Max-Forwards:
70#015#012Event: dialog#015#012Contact:
<sip:10.16.48.44:5060>#015#012Subscription-State:
active;expires=1799#015#012Content-Type: application/dialog-info+xml#015#012
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:926]: ps_build_dlg_t(): CONTACT = sip:116633 at 10.16.48.14:5070
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:1574]: send_notify_request(): expires 1799 status 1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:1727]: shm_dup_cbparam(): === 22/6/37
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: INFO:
presence [notify.c:1601]: send_notify_request(): NOTIFY sip:116633 at 10.16.48.14
via sip:116633 at 10.16.48.14:5070 on behalf of sip:116001 at 10.16.48.44 for event
dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21025]: DEBUG:
presence [notify.c:1701]: p_tm_callback(): completed with status 200
[to_tag:4f7a7e54f75c89f5b968c90011d693b5-9ec9]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140507/48fe835c/attachment.html>
More information about the sr-users
mailing list