[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