[Freeswitch-dev] Dialog events

[Anthony Minessale]

The reason for this is because we don't care about any calls who are
not registered to us.
The sip_dialogs table are purely for in-call presence information of
authenticated users.

PRESENCE_PROBE is, in essence a query to see who is currently registered.

Maybe if you describe your paradigm to me that does not involve any
registrations, I can come up with a better answer.


On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn)
<cbeeton at avaya.com> wrote:
> 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 at lists.freeswitch.org
>> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On
>> Behalf Of Anthony Minessale
>> Sent: Friday, October 08, 2010 5:32 PM
>> To: freeswitch-dev at 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.
>>
>
> _______________________________________________
> 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