[Freeswitch-dev] Dialog events

Anthony Minessale anthony.minessale at gmail.com
Tue Oct 12 10:46:43 PDT 2010 

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