[SR-Users] Does Kamailio not support multiple dialog elements in NOTIFY requests of the event "dialog"?
Klaus Feichtinger
klaus.lists at inode.at
Wed Apr 30 17:12:40 CEST 2014
Hi Daniel,
thx for you hint. I´m currently working on extending DBG output on several
places / files.
In the meantime I´ve found that the presence_dialoginfo module is still able to
aggregate XML bodies. But - and that´s what I wonder about - only when the XML
bodies were "delivered" to the server in individual PUBLISH requests with single
dialog elements only. As soon as the same information is sent to the server in
form of a single PUBLISH request with two dialog elements, only one element is
returned to the active_watchers.
Until now debug output delivered following information:
(1) the DB is storing correct content of the PUBLISH request in the presentity
table, which looks like this:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000004"
state="full" entity="sip:117103 at 172.31.60.87">
<dialog id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA at 172.31.60.13"
call-id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA at 172.31.60.13"
direction="recipient">
<state>terminated</state>
<remote>
<identity>sip:1101015004 at 172.31.60.13</identity>
<target uri="sip:1101015004 at 172.31.60.13"/>
</remote>
<local>
<identity>sip:117103 at 172.31.60.87</identity>
<target uri="sip:117103 at 172.31.60.87"/>
</local>
</dialog>
<dialog id="1041054395-29684904-1398759995534 at 172.31.60.53"
call-id="1041054395-29684904-1398759995534 at 172.31.60.53" direction="initiator">
<state>confirmed</state>
<remote>
<identity>sip:117101 at 172.31.60.87</identity>
<target uri="sip:117101 at 172.31.60.87"/>
</remote>
<local>
<identity>sip:117103 at 172.31.60.87</identity>
<target uri="sip:117103 at 172.31.60.87"/>
</local>
</dialog>
</dialog-info>
(2) according output of the DBG code line 'LM_DBG("KLAUS - body = %.*s \n",
STR_FMT(body));', which is inserted before 'return body' in the 'agregate_xml'
function, the return value of the agregate_xml function looks like this:
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000"
state="full" entity="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="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-info>#012
It seems that the first dialog element of the DB entry above is returned twice
and the second dialog element is missing here! Does anybody have a hint, why the
function is returning such a malformed result??? Double entries are not
supported and that´s why the NOTIFY message is including only one dialog
element.
Thanks for any hint!
br
Klaus
> Daniel-Constantin Mierla <miconda at gmail.com> hat am 29. April 2014 um 21:23
> geschrieben:
>
> Hello,
>
> a quick look in the code seems to use all xml nodes. Mybe you can add some
> debug messages in presence_dialoginfo/notify_body.c in agregate_xmls()
> functions and see what is not executing.
>
> Daniel
>
> On 29/04/14 20:39, Klaus Feichtinger wrote:
>
> > > Hi,
> >
> > I have a question regarding the presence + presence_dialoginfo modules
> > of Kamailio (tested with version 3.2.x and 3.3.x).
> >
> > My SIP user agents are generating SIP PUBLISH requests for the event
> > “dialog” and some of these PUBLISH requests contain multiple dialog elements
> > in the message body. Kamailio is accepting content of these messages and
> > storing that information in the “presentity” table of the corresponding DB.
> > Taking a look into the presentity table is confirming that both dialog
> > elements of the PUBLISH request are stored (as body content).
> >
> > However, why does the SIP NOTIFY request, which is sent to the
> > "active_watchers" of this event, contain only one of these dialog entries –
> > even that the modparam “force_single_dialog” is set to “0” or (for
> > comparison) unset (using default value "0")? Are multiple dialog entries not
> > / no longer supported by the Kamailio “presence_dialoginfo” module? The
> > README of this module (through all versions incl. 4.1.x) is explaining the
> > opposite:
> > [...]
> > This module by default does body aggregation. [...] e.g. if the entity
> > has multiple dialogs the pua_dialoginfo will send multiple PUBLISH), the
> > module will parse all the received (and still valid, depending on the
> > Expires header in the PUBLISH request) XML documents and generate a single
> > XML document with multiple "dialog" elements.
> > [...]
> >
> > Exemplary content of a PUBLISH request looks like this:
> >
> > PUBLISH sip:117104 at 172.31.60.87 <mailto:sip:117104 at 172.31.60.87>
> > SIP/2.0
> > Via: SIP/2.0/UDP 172.31.60.54:5060;rport;branch=z9hG4bK1118069411
> > From: <sip:117104 at 172.31.60.87> <mailto:sip:117104 at 172.31.60.87>
> > ;tag=4024173055-29882384-1398422652889
> > To: <sip:117104 at 172.31.60.87> <mailto:sip:117104 at 172.31.60.87>
> > Call-ID: 4044398119-29882384-1398422652889 at 172.31.60.54
> > <mailto:4044398119-29882384-1398422652889 at 172.31.60.54>
> > CSeq: 21 PUBLISH
> > Max-Forwards: 70
> > Content-Disposition: render;handling=required
> > Expires: 600
> > Event: dialog
> > Content-Type: application/dialog-info+xml
> > Content-Length: 1053
> >
> > <?xml version="1.0"?>
> > <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
> > version="00000000004" state="full" entity="sip:117104 at 172.31.60.87"
> > <mailto:sip:117104 at 172.31.60.87> >
> > <dialog id="4044468572-29882384-1398422652855 at 172.31.60.54"
> > <mailto:4044468572-29882384-1398422652855 at 172.31.60.54>
> > call-id="4044468572-29882384-1398422652855 at 172.31.60.54"
> > <mailto:4044468572-29882384-1398422652855 at 172.31.60.54>
> > direction="initiator">
> > <state>terminated</state>
> > <remote>
> > <identity>sip:1101015004 at 172.31.60.13
> > <mailto:sip:1101015004 at 172.31.60.13> </identity>
> > <target uri="sip:1101015004 at 172.31.60.13"
> > <mailto:sip:1101015004 at 172.31.60.13> />
> > </remote>
> > <local>
> > <identity>sip:117104 at 172.31.60.87
> > <mailto:sip:117104 at 172.31.60.87> </identity>
> > <target uri="sip:117104 at 172.31.60.87"
> > <mailto:sip:117104 at 172.31.60.87> />
> > </local>
> > </dialog>
> > <dialog id="2310720239-29882384-1398422648572 at 172.31.60.54"
> > <mailto:2310720239-29882384-1398422648572 at 172.31.60.54>
> > call-id="2310720239-29882384-1398422648572 at 172.31.60.54"
> > <mailto:2310720239-29882384-1398422648572 at 172.31.60.54>
> > direction="initiator">
> > <state>confirmed</state>
> > <remote>
> > <identity>sip:117103 at 172.31.60.87
> > <mailto:sip:117103 at 172.31.60.87> </identity>
> > <target uri="sip:117103 at 172.31.60.87"
> > <mailto:sip:117103 at 172.31.60.87> />
> > </remote>
> > <local>
> > <identity>sip:117104 at 172.31.60.87
> > <mailto:sip:117104 at 172.31.60.87> </identity>
> > <target uri="sip:117104 at 172.31.60.87"
> > <mailto:sip:117104 at 172.31.60.87> />
> > </local>
> > </dialog>
> > </dialog-info>
> >
> > Exemplary content of the NOTIFY request looks like this:
> >
> > NOTIFY sip:117101 at 172.31.60.54:5060
> > <mailto:sip:117101 at 172.31.60.54:5060> SIP/2.0
> > Via: SIP/2.0/UDP
> > 172.31.60.87;branch=z9hG4bKaeb3.066c77d0000000000000000000000000.0
> > To: sip:117101 at 172.31.60.87;tag=827287863-29882384-1398420840764
> > <mailto:sip:117101 at 172.31.60.87;tag=827287863-29882384-1398420840764>
> > From: sip:117104 at 172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a
> > <mailto:sip:117104 at 172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a>
> > CSeq: 152 NOTIFY
> > Call-ID: 1176683682-29882384-1398420840764 at 172.31.60.54
> > <mailto:1176683682-29882384-1398420840764 at 172.31.60.54>
> > Content-Length: 600
> > User-Agent: kamailio (3.2.4 (i386/linux))
> > Max-Forwards: 70
> > Event: dialog
> > Contact: <sip:172.31.60.87:5060> <sip:172.31.60.87:5060>
> > Subscription-State: active;expires=1370
> > Content-Type: application/dialog-info+xml
> >
> > <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
> > version="00000000004" state="full" entity= "sip:117104 at 172.31.60.87"
> > <mailto:sip:117104 at 172.31.60.87> >
> > <dialog id= "4044468572-29882384-1398422652855 at 172.31.60.54"
> > <mailto:4044468572-29882384-1398422652855 at 172.31.60.54> call-id=
> > "4044468572-29882384-1398422652855 at 172.31.60.54"
> > <mailto:4044468572-29882384-1398422652855 at 172.31.60.54>
> > direction="initiator">
> > <state>terminated</state>
> > <remote>
> > <identity> sip:1101015004 at 172.31.60.13
> > <mailto:sip:1101015004 at 172.31.60.13> </identity>
> > <target uri= "sip:1101015004 at 172.31.60.13"
> > <mailto:sip:1101015004 at 172.31.60.13> />
> > </remote>
> > <local>
> > <identity> sip:117104 at 172.31.60.87
> > <mailto:sip:117104 at 172.31.60.87> </identity>
> > <target uri= "sip:117104 at 172.31.60.87"
> > <mailto:sip:117104 at 172.31.60.87> />
> > </local>
> > </dialog>
> > </dialog-info>
> >
> > In other words: it is not inserting all (stored) dialog elements into
> > the notification request. Please give me a hint, what there could be wrong.
> > Maybe it is just a misunderstanding of the description.....
> >
> > Br
> > Klaus
> >
> >
> >
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
> > <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
> >
> > >
> --
> 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/20140430/b601280a/attachment.html>
More information about the sr-users
mailing list