[Freeswitch-dev] Dialog events
Beeton, Carolyn (Carolyn)
cbeeton at avaya.com
Tue Oct 12 10:10:35 PDT 2010
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
>
More information about the FreeSWITCH-dev
mailing list