Hello,

can you send the patch to be reviewed?

Cheers,
Daniel

On 07/05/14 13:15, Klaus Feichtinger wrote:
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@10.16.48.44">#012  <dialog id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13" call-id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13" direction="recipient">#012<state>terminated</state>#012<remote>#012<identity>sip:1101015004@172.31.60.13</identity>#012<target uri="sip:1101015004@172.31.60.13"/>#012</remote>#012<local>#012<identity>sip:117103@172.31.60.87</identity>#012<target uri="sip:117103@172.31.60.87"/>#012</local>#012</dialog>#012  <dialog id="1041054395-29684904-1398759995534@172.31.60.53" call-id="1041054395-29684904-1398759995534@172.31.60.53" direction="initiator">#012<state>confirmed</state>#012<remote>#012<identity>sip:117101@172.31.60.87</identity>#012<target uri="sip:117101@172.31.60.87"/>#012</remote>#012<local>#012<identity>sip:117103@172.31.60.87</identity>#012<target uri="sip:117103@172.31.60.87"/>#012</local>#012</dialog>#012  <dialog id="2081054457-54683129-1398759736821@172.31.60.54" call-id="2081054457-54683129-1398759736821@172.31.60.54" direction="recipient">#012<state>alerting</state>#012<remote>#012<identity>sip:1101015005@172.31.60.87</identity>#012<target uri="sip:1101015005@172.31.60.87"/>#012</remote>#012<local>#012<identity>sip:117103@172.31.60.87</identity>#012<target uri="sip:117103@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@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@10.16.48.14 via sip:116633@10.16.48.14:5070 on behalf of sip:116001@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] 


-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda