[SR-Users] Kamailio NOTIFY

Klaus Darilion klaus.mailinglists at pernau.at
Fri Feb 11 10:34:02 CET 2011



Am 11.02.2011 07:57, schrieb Spinov Evgeniy:
> Thank you for detailed explanation, now I've got it, but I'm confused
> about workaround. Really nothing could be done to send phone offline or
> get it online when it's off? For instance to get it online, it's
> possible to emulate false call, with INVITE, for instance.
> 
> Have you tried something like that?

Again: There is now way to signal 'offline' in a 'dialog' info - there
is no XML syntax defined for that. But there is 'offline' in 'presence'
info which can be triggered, e.g:
http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_usrloc.html

klaus

> 
> On Fri, 2011-02-11 at 01:28 +0100, Klaus Darilion wrote:
>> Spinov Evgeniy wrote:
>>> On Wed, 2011-02-09 at 16:24 +0100, Klaus Darilion wrote:
>>>
>>> Thank you for the links, especially this one
>>> http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_dialoginfo.html#id2887055
>>>
>>> I've missed this section while read README. I've fixed that out and made
>>> it working for INVITE requests. I.e. when I'm making a call, status is
>>> displayed normally, and when call is hanged - status is online again.
>>> That works correctly. 
>>>
>>> However I cannot get, how to get it working for REGISTER requests, i.e.
>>> when the phone was down and I'm registering - it's not coming online on
>>> SPA until the first call. And when I'm going offline - unregistering,
>>> I'm still online.
>>
>> Don't confuse 'presence' with 'dialog'info events. 'Presence' allows 
>> offline/online/away/busy/atlunch/... status of presentities (phones).
>>
>> 'dialog' gives you detailed dialog statistics like idle/busy/ringing 
>> with callids/totag/fromtag... so you can for example pick up a call. 
>> That's why nothing happens on REGISTER because REGISTER does not create 
>> a dialog. There is also no workaround as the 'dialog' event has not 
>> states to publish offline/online.
>>
>> regards
>> Klaus
>>
>>> PUBLISH requests are sent, but they are presence type. According to
>>> debug, dialog processing request and assigning hash to it and after
>>> dialog, pua is sending PUBLISH with event presence. pua_dialoginfo never
>>> come up in request.
>>>
>>> Dialog processing is very simple:
>>>
>>> if (is_method("INVITE|REGISTER")) {               
>>> 	dlg_manage();
>>> }
>>>
>>> Somewhy, pua_dialoginfo comes with INVITE request and never comes with
>>> REGISTER.
>>>
>>> Any ideas?
>>>
>>>
>>>> Am 09.02.2011 14:56, schrieb Spinov Evgeniy:
>>>>> On Wed, 2011-02-09 at 14:47 +0100, Klaus Darilion wrote:
>>>>>> Do you see PUBLISH requests with Event: dialog?
>>>>>>
>>>>>> Note: those will be sent by pua_dialoginfo module to Kamailio itslef,
>>>>>> thus will be sent on the loopback interface. You should see them with
>>>>>> "ngrep -d any port 5060"
>>>>>>
>>>>>> klaus
>>>>> No, PUBLISH requests with event dialog are not generated. Instead of
>>>>> dialog event, presence event is generated, but as for me, it should
>>>>> work, as for instance eyeBeam is generating PUBLISH requests itself,
>>>>> with event: presence.
>>>>>
>>>>> You're saying that NOTIFYs with event dialog are empty, cause there are
>>>>> not PUBLISH event: dialog?
>>>> Yes. The "presence server" is just a relay of the content:
>>>>
>>>>
>>>>
>>>> PUBLISH ---> presence server <---SUBSCRIBE/NOTIFY---> client
>>>>
>>>> If dialoginfo is not published into the presence server, the presence
>>>> server will send empty NOTIFYs.
>>>>
>>>> There are 2 ways to get the dialoginfo published into the presence
>>>> server: either the phone does it (e.g. SNOM phones can do that, eyebeam
>>>> only publishes "presence" but not "dialog"info) or Kamailio can PUBLISH
>>>> the dialog state. See
>>>> http://www.kamailio.org/docs/modules/3.1.x/modules_k/presence_dialoginfo.html
>>>>
>>>> So, make sure that Kamailio will publish the dialoginfo:
>>>> http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_dialoginfo.html#id2887055
>>>>
>>>> regards
>>>> klaus
>>>
>>>
> 
> 



More information about the sr-users mailing list