[SR-Users] UPDATE --- Can "presence" module handle publish reqs with several dialog entries? + Problem SOLUTION

[Klaus Feichtinger]

Pls find attached the patch for version 4.1.3. The three lines of code are equal
for all affected version (incl. 3.2.4, 3.3.5, 4.0.6 and 4.1.3).

regards,
Klaus

> Daniel-Constantin Mierla <miconda at gmail.com> hat am 7. Mai 2014 um 15:45
> geschrieben:
> 
>  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
> > 
> > 
> >  >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140507/510168a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: notify_body.c.4-1-3.patch
Type: application/octet-stream
Size: 739 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140507/510168a4/attachment.obj>