Does Kamailio not support multiple dialog elements in NOTIFY requests of the event "dialog"?
29 Apr
2014
29 Apr
'14
9:39 p.m.
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@172.31.60.87 SIP/2.0
Via: SIP/2.0/UDP 172.31.60.54:5060;rport;branch=z9hG4bK1118069411
From: <sip:117104@172.31.60.87>;tag=4024173055-29882384-1398422652889
To: <sip:117104@172.31.60.87>
Call-ID: 4044398119-29882384-1398422652889(a)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@172.31.60.87">
<dialog id="4044468572-29882384-1398422652855(a)172.31.60.54"
call-id="4044468572-29882384-1398422652855(a)172.31.60.54"
direction="initiator">
<state>terminated</state>
<remote>
<identity>sip:1101015004@172.31.60.13</identity>
<target uri="sip:1101015004@172.31.60.13"/>
</remote>
<local>
<identity>sip:117104@172.31.60.87</identity>
<target uri="sip:117104@172.31.60.87"/>
</local>
</dialog>
<dialog id="2310720239-29882384-1398422648572(a)172.31.60.54"
call-id="2310720239-29882384-1398422648572(a)172.31.60.54"
direction="initiator">
<state>confirmed</state>
<remote>
<identity>sip:117103@172.31.60.87</identity>
<target uri="sip:117103@172.31.60.87"/>
</remote>
<local>
<identity>sip:117104@172.31.60.87</identity>
<target uri="sip:117104@172.31.60.87"/>
</local>
</dialog>
</dialog-info>
Exemplary content of the NOTIFY request looks like this:
NOTIFY sip:117101@172.31.60.54:5060 SIP/2.0
Via: SIP/2.0/UDP
172.31.60.87;branch=z9hG4bKaeb3.066c77d0000000000000000000000000.0
To: sip:117101@172.31.60.87;tag=827287863-29882384-1398420840764
From: sip:117104@172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a
CSeq: 152 NOTIFY
Call-ID: 1176683682-29882384-1398420840764(a)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>
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@172.31.60.87">
<dialog id="4044468572-29882384-1398422652855(a)172.31.60.54"
call-id="4044468572-29882384-1398422652855(a)172.31.60.54"
direction="initiator">
<state>terminated</state>
<remote>
<identity>sip:1101015004@172.31.60.13</identity>
<target uri="sip:1101015004@172.31.60.13"/>
</remote>
<local>
<identity>sip:117104@172.31.60.87</identity>
<target uri="sip:117104@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
29 Apr
29 Apr
10:23 p.m.
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@172.31.60.87 SIP/2.0
Via: SIP/2.0/UDP 172.31.60.54:5060;rport;branch=z9hG4bK1118069411
From: <sip:117104@172.31.60.87>;tag=4024173055-29882384-1398422652889
To: <sip:117104@172.31.60.87>
Call-ID: 4044398119-29882384-1398422652889(a)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@172.31.60.87">
<dialog id="4044468572-29882384-1398422652855(a)172.31.60.54"
call-id="4044468572-29882384-1398422652855(a)172.31.60.54"
direction="initiator">
<state>terminated</state>
<remote>
<identity>sip:1101015004@172.31.60.13</identity>
<target uri="sip:1101015004@172.31.60.13"/>
</remote>
<local>
<identity>sip:117104@172.31.60.87</identity>
<target uri="sip:117104@172.31.60.87"/>
</local>
</dialog>
<dialog id="2310720239-29882384-1398422648572(a)172.31.60.54"
call-id="2310720239-29882384-1398422648572(a)172.31.60.54"
direction="initiator">
<state>confirmed</state>
<remote>
<identity>sip:117103@172.31.60.87</identity>
<target uri="sip:117103@172.31.60.87"/>
</remote>
<local>
<identity>sip:117104@172.31.60.87</identity>
<target uri="sip:117104@172.31.60.87"/>
</local>
</dialog>
</dialog-info>
Exemplary content of the NOTIFY request looks like this:
NOTIFY sip:117101@172.31.60.54:5060 SIP/2.0
Via: SIP/2.0/UDP
172.31.60.87;branch=z9hG4bKaeb3.066c77d0000000000000000000000000.0
To: sip:117101@172.31.60.87;tag=827287863-29882384-1398420840764
From: sip:117104@172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a
CSeq: 152 NOTIFY
Call-ID: 1176683682-29882384-1398420840764(a)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>
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@172.31.60.87">
<dialog id="4044468572-29882384-1398422652855(a)172.31.60.54"
call-id="4044468572-29882384-1398422652855(a)172.31.60.54"
direction="initiator">
<state>terminated</state>
<remote>
<identity>sip:1101015004@172.31.60.13</identity>
<target uri="sip:1101015004@172.31.60.13"/>
</remote>
<local>
<identity>sip:117104@172.31.60.87</identity>
<target uri="sip:117104@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(a)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
30 Apr
30 Apr
6:12 p.m.
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@172.31.60.87">
<dialog id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA(a)172.31.60.13"
call-id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA(a)172.31.60.13"
direction="recipient">
<state>terminated</state>
<remote>
<identity>sip:1101015004@172.31.60.13</identity>
<target uri="sip:1101015004@172.31.60.13"/>
</remote>
<local>
<identity>sip:117103@172.31.60.87</identity>
<target uri="sip:117103@172.31.60.87"/>
</local>
</dialog>
<dialog id="1041054395-29684904-1398759995534(a)172.31.60.53"
call-id="1041054395-29684904-1398759995534(a)172.31.60.53"
direction="initiator">
<state>confirmed</state>
<remote>
<identity>sip:117101@172.31.60.87</identity>
<target uri="sip:117101@172.31.60.87"/>
</remote>
<local>
<identity>sip:117103@172.31.60.87</identity>
<target uri="sip:117103@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(a)10.16.48.44">#012<dialog
id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA(a)172.31.60.13"
call-id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA(a)172.31.60.13"
direction="recipient">#012<state>terminated</state>#012<remote>#012<identity>sip:1101015004@172.31.60.13</identity>#012<target
uri="sip:1101015004@172.31.60.13"/>#012</remote>#012<local>#012<identity>sip:117103@172.31.60.87</identity>#012<target
uri="sip:117103@172.31.60.87"/>#012</local>#012</dialog>#012<dialog
id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA(a)172.31.60.13"
call-id="CBE263FF-CEAE11E3-80E8CCBC-52135ACA(a)172.31.60.13"
direction="recipient">#012<state>terminated</state>#012<remote>#012<identity>sip:1101015004@172.31.60.13</identity>#012<target
uri="sip:1101015004@172.31.60.13"/>#012</remote>#012<local>#012<identity>sip:117103@172.31.60.87</identity>#012<target
uri="sip:117103@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(a)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:
--
Daniel-Constantin Mierla - <http://www.asipto.com>
<http://twitter.com/#!/miconda> - <http://www.linkedin.com/in/miconda>
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@172.31.60.87 <mailto:sip:117104@172.31.60.87>
SIP/2.0
Via: SIP/2.0/UDP 172.31.60.54:5060;rport;branch=z9hG4bK1118069411
From: <sip:117104@172.31.60.87> <mailto:sip:117104@172.31.60.87>
;tag=4024173055-29882384-1398422652889
To: <sip:117104@172.31.60.87> <mailto:sip:117104@172.31.60.87>
Call-ID: 4044398119-29882384-1398422652889(a)172.31.60.54
<mailto:4044398119-29882384-1398422652889@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@172.31.60.87"
<mailto:sip:117104@172.31.60.87> >
<dialog id="4044468572-29882384-1398422652855(a)172.31.60.54"
<mailto:4044468572-29882384-1398422652855@172.31.60.54>
call-id="4044468572-29882384-1398422652855(a)172.31.60.54"
<mailto:4044468572-29882384-1398422652855@172.31.60.54>
direction="initiator">
<state>terminated</state>
<remote>
<identity>sip:1101015004@172.31.60.13
<mailto:sip:1101015004@172.31.60.13> </identity>
<target uri="sip:1101015004@172.31.60.13"
<mailto:sip:1101015004@172.31.60.13> />
</remote>
<local>
<identity>sip:117104@172.31.60.87
<mailto:sip:117104@172.31.60.87> </identity>
<target uri="sip:117104@172.31.60.87"
<mailto:sip:117104@172.31.60.87> />
</local>
</dialog>
<dialog id="2310720239-29882384-1398422648572(a)172.31.60.54"
<mailto:2310720239-29882384-1398422648572@172.31.60.54>
call-id="2310720239-29882384-1398422648572(a)172.31.60.54"
<mailto:2310720239-29882384-1398422648572@172.31.60.54>
direction="initiator">
<state>confirmed</state>
<remote>
<identity>sip:117103@172.31.60.87
<mailto:sip:117103@172.31.60.87> </identity>
<target uri="sip:117103@172.31.60.87"
<mailto:sip:117103@172.31.60.87> />
</remote>
<local>
<identity>sip:117104@172.31.60.87
<mailto:sip:117104@172.31.60.87> </identity>
<target uri="sip:117104@172.31.60.87"
<mailto:sip:117104@172.31.60.87> />
</local>
</dialog>
</dialog-info>
Exemplary content of the NOTIFY request looks like this:
NOTIFY sip:117101@172.31.60.54:5060
<mailto:sip:117101@172.31.60.54:5060> SIP/2.0
Via: SIP/2.0/UDP
172.31.60.87;branch=z9hG4bKaeb3.066c77d0000000000000000000000000.0
To: sip:117101@172.31.60.87;tag=827287863-29882384-1398420840764
<mailto:sip:117101@172.31.60.87;tag=827287863-29882384-1398420840764>
From: sip:117104@172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a
<mailto:sip:117104@172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a>
CSeq: 152 NOTIFY
Call-ID: 1176683682-29882384-1398420840764(a)172.31.60.54
<mailto:1176683682-29882384-1398420840764@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@172.31.60.87"
<mailto:sip:117104@172.31.60.87> >
<dialog id= "4044468572-29882384-1398422652855(a)172.31.60.54"
<mailto:4044468572-29882384-1398422652855@172.31.60.54> call-id=
"4044468572-29882384-1398422652855(a)172.31.60.54"
<mailto:4044468572-29882384-1398422652855@172.31.60.54>
direction="initiator">
<state>terminated</state>
<remote>
<identity> sip:1101015004@172.31.60.13
<mailto:sip:1101015004@172.31.60.13> </identity>
<target uri= "sip:1101015004@172.31.60.13"
<mailto:sip:1101015004@172.31.60.13> />
</remote>
<local>
<identity> sip:117104@172.31.60.87
<mailto:sip:117104@172.31.60.87> </identity>
<target uri= "sip:117104@172.31.60.87"
<mailto:sip:117104@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(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>
3859
days inactive
3860
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Klaus Feichtinger