[SR-Users] Does Kamailio not support multiple dialog elements in NOTIFY requests of the event "dialog"?

Daniel-Constantin Mierla miconda at gmail.com
Tue Apr 29 21:23:13 CEST 2014


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 SIP/2.0
> Via: SIP/2.0/UDP 172.31.60.54:5060;rport;branch=z9hG4bK1118069411
> From: <sip:117104 at 172.31.60.87>;tag=4024173055-29882384-1398422652889
> To: <sip:117104 at 172.31.60.87>
> Call-ID: 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">
>   <dialog id="4044468572-29882384-1398422652855 at 172.31.60.54" 
> call-id="4044468572-29882384-1398422652855 at 172.31.60.54" 
> direction="initiator">
>     <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:117104 at 172.31.60.87</identity>
>       <target uri="sip:117104 at 172.31.60.87"/>
>     </local>
>   </dialog>
>   <dialog id="2310720239-29882384-1398422648572 at 172.31.60.54" 
> call-id="2310720239-29882384-1398422648572 at 172.31.60.54" 
> direction="initiator">
>     <state>confirmed</state>
>     <remote>
>       <identity>sip:117103 at 172.31.60.87</identity>
>       <target uri="sip:117103 at 172.31.60.87"/>
>     </remote>
>     <local>
>       <identity>sip:117104 at 172.31.60.87</identity>
>       <target uri="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 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
> From: sip:117104 at 172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a
> CSeq: 152 NOTIFY
> Call-ID: 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>
> 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">
>   <dialog id="4044468572-29882384-1398422652855 at 172.31.60.54" 
> call-id="4044468572-29882384-1398422652855 at 172.31.60.54" 
> direction="initiator">
>     <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:117104 at 172.31.60.87</identity>
>       <target uri="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
> 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/20140429/35e4447d/attachment.html>


More information about the sr-users mailing list