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

Klaus Feichtinger klaus.lists at inode.at
Mon May 5 16:28:18 CEST 2014 

this is the output (in this example version 3.2.4) in debug level 3 after
receiving a PUBLISH request (incl. forming the NOTIFY request):

May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[event_list.c:350]: start event= [dialog/5]
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[publish.c:349]: SIP-If-Match header not found
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[presentity.c:85]: etag= a.1399299676.23439.2.0 / 22#012
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[publish.c:358]: new etag  = a.1399299676.23439.2.0
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[publish.c:383]: Expires header found, value= 1800
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[publish.c:468]: KLAUSDBG - body = <?xml version="1.0"?>#015#012<dialog-info
xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000004" state="full"
entity="sip:117103 at 172.31.60.87">#015#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">#015#012<state>terminated</state>#015#012<remote>#015#012<identity>sip:1101015004 at 172.31.60.13</identity>#015#012<target
uri="sip:1101015004 at 172.31.60.13"/>#015#012</remote>#015#012<local>#015#012<identity>sip:117103 at 172.31.60.87</identity>#015#012<target
uri="sip:117103 at 172.31.60.87"/>#015#012</local>#015#012</dialog>#015#012<dialog
id="1041054395-29684904-1398759995534 at 172.31.60.53"
call-id="1041054395-29684904-1398759995534 at 172.31.60.53"
direction="initiator">#015#012<state>confirmed</state>#015#012<remote>#015#012<identity>sip:117101 at 172.31.60.87</identity>#015#012<target
uri="sip:117101 at 172.31.60.87"/>#015#012</remote>#015#012<local>#015#012<identity>sip:117103 at 172.31.60.87</identity>#015#012<target
uri="sip:117103 at 172.31.60.87"/>#015#012</local>#015#012</dialog>#015#012</dialog-info>#015#012
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[hash.c:470]: pres_uri= sip:116001 at 10.16.48.44
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[presentity.c:385]: inserting 8 cols into table
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[presentity.c:99]: send 200OK reply
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[presentity.c:100]: etag= a.1399299676.23439.2.0 - len= 22
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1041]: querying database table = active_watchers
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1116]: found 1 dialogs
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:122]: #012#011[pres_uri]= sip:116001 at 10.16.48.44#012#011[to_user]=
116001#011[to_domain]= 10.16.48.44#012#011[w_user]= 117700#011[w_domain]=
10.16.48.14#012#011[event]= dialog#012#011[status]= active#012#011[expires]=
889#012#011[callid]= 1146821297#011[local_cseq]=1#012#011[to_tag]=
4f7a7e54f75c89f5b968c90011d693b5-8c7d#011[from_tag]= 154174339#012#011[contact]=
sip:117700 at 10.16.48.14:5070#011[record_route]=
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1333]: found 1 dialogs( 1 in database and 0 in hash_table)
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:782]: Event requires aggregation
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG:
presence_dialoginfo [notify_body.c:67]: [pres_user]=116001 [pres_domain]=
10.16.48.44, [n]=1
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG:
presence_dialoginfo [notify_body.c:107]: [pres_user]=116001 [pres_domain]=
10.16.48.44, [n]=1
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG:
presence_dialoginfo [notify_body.c:199]: node type: Element, name: dialog
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG:
presence_dialoginfo [notify_body.c:73]: [n_body]=0xb7a6daa4
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG:
presence_dialoginfo [notify_body.c:76]: [*n_body]=<?xml
version="1.0"?>#012<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-info>#012
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG:
presence_dialoginfo [notify_body.c:328]: replace version with "1"
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1651]: updating subscription to database
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1468]: dialog info:
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:122]: #012#011[pres_uri]= sip:116001 at 10.16.48.44#012#011[to_user]=
116001#011[to_domain]= 10.16.48.44#012#011[w_user]= 117700#011[w_domain]=
10.16.48.14#012#011[event]= dialog#012#011[status]= active#012#011[expires]=
889#012#011[callid]= 1146821297#011[local_cseq]=1#012#011[to_tag]=
4f7a7e54f75c89f5b968c90011d693b5-8c7d#011[from_tag]= 154174339#012#011[contact]=
sip:117700 at 10.16.48.14:5070#011[record_route]=
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:236]: expires = 889
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1562]: headers:#012Max-Forwards: 70#015#012Event:
dialog#015#012Contact: <sip:10.16.48.44:5060>#015#012Subscription-State:
active;expires=870#015#012Content-Type: application/dialog-info+xml#015#012
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:964]: CONTACT = sip:117700 at 10.16.48.14:5070
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1724]: === 22/6/37
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: INFO: presence
[notify.c:1593]: NOTIFY sip:117700 at 10.16.48.14 via sip:117700 at 10.16.48.14:5070
on behalf of sip:116001 at 10.16.48.44 for event dialog
May  5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence
[notify.c:1689]: completed with status 200
[to_tag:4f7a7e54f75c89f5b968c90011d693b5-8c7d]


Main visible difference is the xml body output between PUBLISH (publish.c) and
NOTIFY (notify_body.c).

regards,
Klaus

> Daniel-Constantin Mierla <miconda at gmail.com> hat am 5. Mai 2014 um 13:27
> geschrieben:
> 
>  Hello,
> 
>  I haven't meet that case yet, but xml aggregation in presence_dialoginfo
> seems to walk through all children of root note for each xml doc. Maybe you
> can post here the output with debug=3.
> 
>  Cheers,
>  Daniel
> 
>  On 05/05/14 13:17, Klaus Feichtinger wrote:
> 
>      > >      Hi,
> > 
> >      during simulating scenarios in relation with the notify problem I have
> > so far, I became unsure, if Kamilio (in principal) is supporting handling of
> > PUBLISH requests (event "dialog") that contain _more than_ one (1) dialog
> > entry. I know that it can generate notify requests with a message body that
> > contains more than one dialog entry. But that´s not automatically the same
> > as handling publish requests....
> > 
> >      So - is Kamailio able or not? Did anybody ever use it in such a
> > scenario?
> > 
> >      regards,
> >      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/20140505/9d831a28/attachment.html>

More information about the sr-users mailing list