[Freeswitch-dev] Dialog events

Anthony Minessale anthony.minessale at gmail.com
Tue Oct 12 11:28:06 PDT 2010 

in this case you could possibly branch off with a 2nd sql stmt when so
configured in the presence_probe handler to do exactly what you want
and select all the same columns

On Tue, Oct 12, 2010 at 1:05 PM, Beeton, Carolyn (Carolyn)
<cbeeton at avaya.com> wrote:
> 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
>>
> _______________________________________________
> 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

More information about the FreeSWITCH-dev mailing list