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@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 10:30 AM To: freeswitch-dev@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@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Friday, October 08, 2010 5:32 PM To: freeswitch-dev@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900