[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