the problem is since loopback is not a real channel type there would not be anything in the sip presence tables for active calls even if you used it. You would see the events change from state to state but you would not have any persistance to pick up on if you started monitoring when the calls was already up. You're only choice would be to override the real presence_id with the var or to add more code to let one leg have multiple presence identities which may be possible but also could prove challenging. The conference uses it's own special distributed namespace inside FS which is delimited by + conf+3001@my.box would allow you to subscribe to conference 3001@my.box you set the my.box domain name in the domain field of conference.conf.xml The default config shows conference 3001 advertised in this manner from the config. On Mon, Nov 15, 2010 at 11:27 AM, Beeton, Carolyn (Carolyn) <cbeeton@avaya.com> wrote:
Now this leads to another question. If I am monitoring an extension which is running a socket application or playback or something like that, I can't do this:
<action application="set" data="presence_id=44@$${domain}"/>
because that really "hijacks" the channel from whoever it actually belongs to, who might have a valid presence_id of their own (i.e. might be a registered set which others are monitoring). (That also might explain why I was seeing the "direction" backwards when monitoring a FS app).
Is the complete solution then to use a bridge application with data="loopback/app=socket...", and set the presence_id of the application extension on the far side of the bridge? i.e. something like this:
<action application="bridge" data="presence_id=44@$${domain};loopback/app=playback..."/>
On a somewhat related note, how does monitoring of conference and park extensions work? Does the presence_id have to be set in the dialplan, or is it done automatically for these applications? When a registered user calls into a conference, would PRESENCE_IN events be generated for both ends of the call?
Carolyn
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Beeton, Carolyn (Carolyn) Sent: Thursday, November 11, 2010 3:25 PM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Question about presence_id
Ok - I think I see now. Changed my dialplan to this:
<extension name="47"> <condition field="destination_number" expression="^47$"> <action application="bridge" data="{presence_id=47@$${domain}}sofia/cbeetonscs.ca.nortel.co m/47%cbeetonscs.ca.nortel.com"/> </condition> </extension> <extension name="49"> <condition field="destination_number" expression="^49$"> <action application="bridge" data="{presence_id=49@$${domain}}sofia/cbeetonscs.ca.nortel.co m/49%cbeetonscs.ca.nortel.com"/> </condition> </extension>
That sets the presence ID for the outgoing legs properly. The presence ID for the incoming leg is set by default by registration. And events are generated as expected and lights work as expected. I just didn't find this bit of info anywhere in the docs!
Carolyn _______________________________________________ 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