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@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@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900