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

Daniel-Constantin Mierla miconda at gmail.com
Thu May 8 08:51:21 CEST 2014


Hello,

thanks, I applied the patch to master and 4.1, plus adapted for 4.0 
branches.

Cheers,
Daniel

On 07/05/14 16:39, Klaus Feichtinger wrote:
> 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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140508/3b77d12c/attachment.html>


More information about the sr-users mailing list