[Freeswitch-dev] Dialog events

Beeton, Carolyn (Carolyn) cbeeton at avaya.com
Tue Oct 12 11:05:54 PDT 2010


I have enabled at least some of the debug.  I will check to see if it is at level 10. 

Our application SUBECRIBEs for dialog events only when it is interested in them, with a very short timeout (ideally 0, but this does not work for some endpoints).  We expect a NOTIFY back giving the current status.  We don't want status events continually, just a single update when we ask for it.  It seems like the code is very close to supporting this.

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: Tuesday, October 12, 2010 1:47 PM
> To: freeswitch-dev at lists.freeswitch.org
> Subject: Re: [Freeswitch-dev] Dialog events
> 
> The presence probe statement you are following is executed 
> when a subscription happens to get the first event.  its a 
> way to make all entities fire a presence event.
> 
> The real presence sql stmt is the one at 698 which does not 
> involve registration and is triggered by presence_in events 
> which will be fired when you set the presence_id.  If you 
> don't have the domains the same and the presence_hosts field 
> set to cover the variants you may get nothing.
> 
> The only real problem I can imagine you are having is getting 
> that first required notify after a subscribe, instead you 
> would not get it until you placed a call.  It would require 
> just blindly accepting subscriptions to everything to do what 
> you want.
> 
> have you enabled debug-presence set to 10 in 
> conf/autoload_configs/sofia.conf.xml ?
> 
> This will show the SQL STMTS ad they are being run and could 
> help you to see what you are missing.
> 
> 
> 
> 
> On Tue, Oct 12, 2010 at 12:10 PM, Beeton, Carolyn (Carolyn) 
> <cbeeton at avaya.com> wrote:
> > I am still only getting the partial dialog-info element, 
> not the full dialog contents that I expect when I subscribe 
> for dialog events.  I get this:
> >
> > <dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\" 
> > version=\"1\" state=\"partial\" entity=\"sip:44 at cbeeton.com\"> 
> > </dialog-info>
> >
> > But not the per-dialog element containing details about 
> active dialogs, e.g.:
> >
> > <dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\" 
> > version=\"1\" state=\"full\" entity=\"sip:44 at cbeeton.com\"> <dialog 
> > id=\"d3d433ce-2324c33e at 10.10.10.116\" 
> > call-id=\"d3d433ce-2324c33e at 10.10.10.116\" 
> local-tag=\"KQcQB9v3rmgpp\" 
> > remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> 
> > <state>confirmed</state> <local> <identity 
> > display=\"44\">sip:44 at 10.10.10.158</identity>
> > <target uri=\"sip:44 at 10.10.10.158\">
> > <param pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local> 
> > <remote> <identity 
> display=\"201-116\">sip:201 at 10.10.10.158</identity>
> > <target uri=\"sip:201 at 10.10.10.116;transport=udp\"/>
> > </remote>
> > </dialog>
> > </dialog-info>
> >
> > This is what I am looking for, but the details are blocked 
> because the query looks in sip_registrations first and there 
> are none.  As you say below, "the only way to really know 
> what state a phone is in, is to check if it's involved in a 
> call or is registered" - but the query is doing effectively 
> "AND is registered"
> >
> > Setting presence_id did not make a difference that I could see.
> >
> > 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: Tuesday, October 12, 2010 11:28 AM
> >> To: freeswitch-dev at lists.freeswitch.org
> >> Subject: Re: [Freeswitch-dev] Dialog events
> >>
> >> Try this:
> >>
> >>  <extension name="44">
> >>    <condition field="destination_number" expression="^44$">
> >>      <action application="set" data="presence_id=44@$${domain}"/>
> >>      <action application="answer"/>
> >>      <action application="sleep" data="1000"/>
> >>      <action application="playback" data="/music/default.wav"/>
> >>    </condition>
> >>  </extension>
> >>
> >> change $${domain} to some other value if you have a manually 
> >> configured domain.
> >>
> >> if you don't set presence_id, you will never see any presence 
> >> messages for that call.
> >>
> >> Setting presence id is critical to get your call to broadcast 
> >> presence events.
> >> The reason we care about registered phones is when you 
> subscribe to 
> >> an extension, it's assumed to represent a phone and the 
> only way to 
> >> really know what state a phone is in, is to check if it's 
> involved in 
> >> a call or is registered, anything else means you have no idea and 
> >> could not report proper presence.
> >>
> >> The sip_dialogs table is not part of the dialog-info stuff so RFC 
> >> quotes would not be appropriate in this case.  This table 
> is just a 
> >> toll FS uses in many instances to track extra info about a 
> sip call 
> >> for various features including sometimes the dialog-info events.
> >>
> >>
> >> On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) 
> >> <cbeeton at avaya.com> wrote:
> >> > OK.  I have configured the freeswitch dialplan to answer
> >> extension 44 and invoke the playback application:
> >> >
> >> >   <extension name="44">
> >> >    <condition field="destination_number" expression="^44$">
> >> >      <action application="answer"/>
> >> >      <action application="sleep" data="1000"/>
> >> >      <action application="playback" data="/music/default.wav"/>
> >> >    </condition>
> >> >  </extension>
> >> >
> >> > Now I want to be able to subscribe to 44@<fs ip:port> to
> >> see what calls are being handled there (this is just a first step 
> >> towards monitoring the calls that FS is handling for us).
> >> >
> >> > PRESENCE_PROBE does not sound like quite the right thing,
> >> then.  But that is what is being triggered by a
> >> SUBSCRIBE(dialog) to that extension.  >From RFC4235:
> >> >
> >> > "The dialog package allows users to subscribe to another
> >> >   user and to receive notification of the changes in state
> >> of INVITE-
> >> >   initiated dialog usages in which the subscribed-to user
> >> is involved."
> >> >
> >> > Nothing in there about being registered or not.
> >> >
> >> > 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: Tuesday, October 12, 2010 10:30 AM
> >> >> To: freeswitch-dev at lists.freeswitch.org
> >> >> Subject: Re: [Freeswitch-dev] Dialog events
> >> >>
> >> >> 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-de
> >> >> v
> >> >> > 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-de
> >> >> v
> >> >> http://www.freeswitch.org
> >> >>
> >> > _______________________________________________
> >> > 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-de
> >> v
> >> > 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-de
> >> v
> >> http://www.freeswitch.org
> >>
> > _______________________________________________
> > 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
> 


More information about the FreeSWITCH-dev mailing list