Most of my changes are a pretty straight-forward extension to add the call-id, local-tag and remote-tag into the <dialog> element. But I am blocked by the sql query in actual_sofia_presence_event_handler which pulls out the rows to work on in the first place (in the SWITCH_EVENT_PRESENCE_PROBE case), because it uses the sip_registrations table as the "master" and does a left join on sip_dialogs and sip_presence to get more data. In my case, there is nothing in sip_registrations, so I get no matches to work on. I realize that changing this query (or any of this stuff) is a risky thing - at this point I am just feeling around to see what might be possible. So my main question right now is: - is it correct to build dialog event content primarily based on the sip_registrations table? Could the query be rejigged so that sip_dialogs is the master and sip_registrations is joined where there is a match? To me, this would seem to be correct, as dialog event contents should have little to do with registrations and should not be primarly driven by them. Carolyn
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Friday, October 08, 2010 5:32 PM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Dialog events
anything can be accepted that keeps things working the way they already do work and more. we can probably add those other things to the dialog table as long as nothing breaks in the process.
I am just trying to warn you that this is heavily depended-upon code by many and it's a critical change to manipulate it and changes should be discussed in detail.