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

Daniel-Constantin Mierla miconda at gmail.com
Wed May 7 15:45:36 CEST 2014


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 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]
>

-- 
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/20140507/a562bce5/attachment.html>


More information about the sr-users mailing list