[Freeswitch-dev] Dialog events

[Anthony Minessale]

be aware that you can't simply change the code to do what you want.
The presence code is very very battle scarred and designed to work a
certain way.

It may deserve to be cleaned up, but it can't be changed very easy.
Its the messiest and my least favorite part of all the code.

We tie in registrations because we have a feature to allow the
monitoring of devices that do not support presence by virtue of
registration and to support the bootstrapping of the presence of
phones who are already idle when a subscriber comes online.

The sip_dialogs table is not for the actual sip_dialogs, it's just for
a few things we need to keep track of for SCA and other demanding
presence protocols.

I recommend you get some polycom phones configured for normal blf AND
shared line broad soft style SCA, some dialog-info devices and some
softphones such as x-lite, eyebeam or bria and register them to
FreeSWITCH and learn how it works together.

We can't touch one line of code in that file that disturbs the
operation of any existing devices that we support.  We did not
implement all of the features in dialog-info, only the ones that any
phone we have used seems to care about and we have had substantial
bounties and contributions to get things working.








On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn)
<cbeeton at avaya.com> wrote:
> I have an application which needs to SUBSCRIBE for Dialog events.  I have
> manage-presence turned on.  I place a call to an extension which is
> configured in the FS dialplan and is answered by FS (for the moment, it is
> just playing music).  If I now SUBSCRIBE for Dialog events for that
> extension, I get only the top-level <dialog-info> element, not the details
> included in the per-dialog <dialog> element (e.g. call id, remote display,
> etc) which are described in RFC4235.
>
> In the code, I see that the query in actual_sofia_presence_event_handler
> does a "join" on sip_registrations to pull out some of the dialog details.
> This means that extensions which do not register never get dialog details.
> In my case, sip_registrations and sip_presence databases are empty, but most
> of the info that should be in the <dialog> element is stored in the
> sip_dialogs database.
>
> Why does the query need sip_registrations or sip_presence?  When I simplify
> this query to remove the references to these databases, I get much closer to
> the data I need.  Isn't all the data we need in the sip_dialogs database?.
> Dialog info should not require registration.
>
> I've noticed some other problems, such as:
> - to and from tags are not saved in sip_dialogs
> - call-id, local-tag, remote-tag are not included in the <dialog> element
> - from_user is never used because from_id is never null (it is set to "" by
> switch_str_nil)
> - remote identity display is not included
> - remote target does not come from the dialog Contact
>
> I've made some changes and verified that a NOTIFY can be crafted which fully
> meets RFC4235 and allows my application to pick up this call (by sending an
> INVITE with REPLACES).  The first step though is to understand the link to
> sip_registrations.
>
> Carolyn
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900