[Freeswitch-dev] Dialog events

[Beeton, Carolyn (Carolyn)]

> -----Original Message-----
> From: freeswitch-dev-bounces at lists.freeswitch.org 
> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On 
> Behalf Of 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.

OK, but does that mean that internal endpoints which are not registered should not get full Dialog events?  Or does it mean that the FS extension itself should be considered one of these "not presence capable" devices, and an entry should be made for it in the registrations table?

> 
> 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.

The dialog events described in RFC4235 need many of these same things.  I added (experimentally, for my own edification, of course) a field for local and remote tag, as these are required for full RFC4235 and draft-anil-sipping-bla and draft-ietf-bliss-shared-appearances.

> 
> 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.
> 
> 

So if it could be extended to support internal freeswitch endpoints, would it be accepted?  Or is it completely off-limits?  Given now that our application cares about all of the features in dialog-info.

Carolyn

> 
> 
> 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
> 
> _______________________________________________
> 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
>