I have an application which needs to SUBSCRIBE for Dialog events. I have manage-presence turned on. I place a call to an extension which is configured in the FS dialplan and is answered by FS (for the moment, it is just playing music). If I now SUBSCRIBE for Dialog events for that extension, I get only the top-level <dialog-info> element, not the details included in the per-dialog <dialog> element (e.g. call id, remote display, etc) which are described in RFC4235. In the code, I see that the query in actual_sofia_presence_event_handler does a "join" on sip_registrations to pull out some of the dialog details. This means that extensions which do not register never get dialog details. In my case, sip_registrations and sip_presence databases are empty, but most of the info that should be in the <dialog> element is stored in the sip_dialogs database. Why does the query need sip_registrations or sip_presence? When I simplify this query to remove the references to these databases, I get much closer to the data I need. Isn't all the data we need in the sip_dialogs database?. Dialog info should not require registration. I've noticed some other problems, such as: - to and from tags are not saved in sip_dialogs - call-id, local-tag, remote-tag are not included in the <dialog> element - from_user is never used because from_id is never null (it is set to "" by switch_str_nil) - remote identity display is not included - remote target does not come from the dialog Contact I've made some changes and verified that a NOTIFY can be crafted which fully meets RFC4235 and allows my application to pick up this call (by sending an INVITE with REPLACES). The first step though is to understand the link to sip_registrations. Carolyn
be aware that you can't simply change the code to do what you want. The presence code is very very battle scarred and designed to work a certain way. It may deserve to be cleaned up, but it can't be changed very easy. Its the messiest and my least favorite part of all the code. We tie in registrations because we have a feature to allow the monitoring of devices that do not support presence by virtue of registration and to support the bootstrapping of the presence of phones who are already idle when a subscriber comes online. The sip_dialogs table is not for the actual sip_dialogs, it's just for a few things we need to keep track of for SCA and other demanding presence protocols. I recommend you get some polycom phones configured for normal blf AND shared line broad soft style SCA, some dialog-info devices and some softphones such as x-lite, eyebeam or bria and register them to FreeSWITCH and learn how it works together. We can't touch one line of code in that file that disturbs the operation of any existing devices that we support. We did not implement all of the features in dialog-info, only the ones that any phone we have used seems to care about and we have had substantial bounties and contributions to get things working. On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn) <cbeeton@avaya.com> wrote:
I have an application which needs to SUBSCRIBE for Dialog events. I have manage-presence turned on. I place a call to an extension which is configured in the FS dialplan and is answered by FS (for the moment, it is just playing music). If I now SUBSCRIBE for Dialog events for that extension, I get only the top-level <dialog-info> element, not the details included in the per-dialog <dialog> element (e.g. call id, remote display, etc) which are described in RFC4235.
In the code, I see that the query in actual_sofia_presence_event_handler does a "join" on sip_registrations to pull out some of the dialog details. This means that extensions which do not register never get dialog details. In my case, sip_registrations and sip_presence databases are empty, but most of the info that should be in the <dialog> element is stored in the sip_dialogs database.
Why does the query need sip_registrations or sip_presence? When I simplify this query to remove the references to these databases, I get much closer to the data I need. Isn't all the data we need in the sip_dialogs database?. Dialog info should not require registration.
I've noticed some other problems, such as: - to and from tags are not saved in sip_dialogs - call-id, local-tag, remote-tag are not included in the <dialog> element - from_user is never used because from_id is never null (it is set to "" by switch_str_nil) - remote identity display is not included - remote target does not come from the dialog Contact
I've made some changes and verified that a NOTIFY can be crafted which fully meets RFC4235 and allows my application to pick up this call (by sending an INVITE with REPLACES). The first step though is to understand the link to sip_registrations.
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
-- 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
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
be aware that you can't simply change the code to do what you want. The presence code is very very battle scarred and designed to work a certain way.
It may deserve to be cleaned up, but it can't be changed very easy. Its the messiest and my least favorite part of all the code.
We tie in registrations because we have a feature to allow the monitoring of devices that do not support presence by virtue of registration and to support the bootstrapping of the presence of phones who are already idle when a subscriber comes online.
OK, but does that mean that internal endpoints which are not registered should not get full Dialog events? Or does it mean that the FS extension itself should be considered one of these "not presence capable" devices, and an entry should be made for it in the registrations table?
The sip_dialogs table is not for the actual sip_dialogs, it's just for a few things we need to keep track of for SCA and other demanding presence protocols.
The dialog events described in RFC4235 need many of these same things. I added (experimentally, for my own edification, of course) a field for local and remote tag, as these are required for full RFC4235 and draft-anil-sipping-bla and draft-ietf-bliss-shared-appearances.
I recommend you get some polycom phones configured for normal blf AND shared line broad soft style SCA, some dialog-info devices and some softphones such as x-lite, eyebeam or bria and register them to FreeSWITCH and learn how it works together.
We can't touch one line of code in that file that disturbs the operation of any existing devices that we support. We did not implement all of the features in dialog-info, only the ones that any phone we have used seems to care about and we have had substantial bounties and contributions to get things working.
So if it could be extended to support internal freeswitch endpoints, would it be accepted? Or is it completely off-limits? Given now that our application cares about all of the features in dialog-info. Carolyn
On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn) <cbeeton@avaya.com> wrote:
I have an application which needs to SUBSCRIBE for Dialog events. I have manage-presence turned on. I place a call to an extension which is configured in the FS dialplan and is answered by FS (for the moment, it is just playing music). If I now SUBSCRIBE for Dialog events for that extension, I get only the top-level <dialog-info> element, not the details included in the per-dialog <dialog> element (e.g. call id, remote display, etc) which are described in RFC4235.
In the code, I see that the query in actual_sofia_presence_event_handler does a "join" on sip_registrations to pull out some of the dialog details. This means that extensions which do not register never get dialog details. In my case, sip_registrations and sip_presence databases are empty, but most of the info that should be in the <dialog> element is stored in the sip_dialogs database.
Why does the query need sip_registrations or sip_presence? When I simplify this query to remove the references to these databases, I get much closer to the data I need. Isn't all the data we need in the sip_dialogs database?. Dialog info should not require registration.
I've noticed some other problems, such as: - to and from tags are not saved in sip_dialogs - call-id, local-tag, remote-tag are not included in the <dialog> element - from_user is never used because from_id is never null (it is set to "" by switch_str_nil) - remote identity display is not included - remote target does not come from the dialog Contact
I've made some changes and verified that a NOTIFY can be crafted which fully meets RFC4235 and allows my application to pick up this call (by sending an INVITE with REPLACES). The first step though is to understand the link to sip_registrations.
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
-- 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
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. On Fri, Oct 8, 2010 at 3:11 PM, Beeton, Carolyn (Carolyn) <cbeeton@avaya.com> wrote:
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
be aware that you can't simply change the code to do what you want. The presence code is very very battle scarred and designed to work a certain way.
It may deserve to be cleaned up, but it can't be changed very easy. Its the messiest and my least favorite part of all the code.
We tie in registrations because we have a feature to allow the monitoring of devices that do not support presence by virtue of registration and to support the bootstrapping of the presence of phones who are already idle when a subscriber comes online.
OK, but does that mean that internal endpoints which are not registered should not get full Dialog events? Or does it mean that the FS extension itself should be considered one of these "not presence capable" devices, and an entry should be made for it in the registrations table?
The sip_dialogs table is not for the actual sip_dialogs, it's just for a few things we need to keep track of for SCA and other demanding presence protocols.
The dialog events described in RFC4235 need many of these same things. I added (experimentally, for my own edification, of course) a field for local and remote tag, as these are required for full RFC4235 and draft-anil-sipping-bla and draft-ietf-bliss-shared-appearances.
I recommend you get some polycom phones configured for normal blf AND shared line broad soft style SCA, some dialog-info devices and some softphones such as x-lite, eyebeam or bria and register them to FreeSWITCH and learn how it works together.
We can't touch one line of code in that file that disturbs the operation of any existing devices that we support. We did not implement all of the features in dialog-info, only the ones that any phone we have used seems to care about and we have had substantial bounties and contributions to get things working.
So if it could be extended to support internal freeswitch endpoints, would it be accepted? Or is it completely off-limits? Given now that our application cares about all of the features in dialog-info.
Carolyn
On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn) <cbeeton@avaya.com> wrote:
I have an application which needs to SUBSCRIBE for Dialog events. I have manage-presence turned on. I place a call to an extension which is configured in the FS dialplan and is answered by FS (for the moment, it is just playing music). If I now SUBSCRIBE for Dialog events for that extension, I get only the top-level <dialog-info> element, not the details included in the per-dialog <dialog> element (e.g. call id, remote display, etc) which are described in RFC4235.
In the code, I see that the query in actual_sofia_presence_event_handler does a "join" on sip_registrations to pull out some of the dialog details. This means that extensions which do not register never get dialog details. In my case, sip_registrations and sip_presence databases are empty, but most of the info that should be in the <dialog> element is stored in the sip_dialogs database.
Why does the query need sip_registrations or sip_presence? When I simplify this query to remove the references to these databases, I get much closer to the data I need. Isn't all the data we need in the sip_dialogs database?. Dialog info should not require registration.
I've noticed some other problems, such as: - to and from tags are not saved in sip_dialogs - call-id, local-tag, remote-tag are not included in the <dialog> element - from_user is never used because from_id is never null (it is set to "" by switch_str_nil) - remote identity display is not included - remote target does not come from the dialog Contact
I've made some changes and verified that a NOTIFY can be crafted which fully meets RFC4235 and allows my application to pick up this call (by sending an INVITE with REPLACES). The first step though is to understand the link to sip_registrations.
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
-- 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
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.
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 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
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
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
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@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@cbeeton.com\"> <dialog id=\"d3d433ce-2324c33e@10.10.10.116\" call-id=\"d3d433ce-2324c33e@10.10.10.116\" local-tag=\"KQcQB9v3rmgpp\" remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> <state>confirmed</state> <local> <identity display=\"44\">sip:44@10.10.10.158</identity> <target uri=\"sip:44@10.10.10.158\"> <param pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local> <remote> <identity display=\"201-116\">sip:201@10.10.10.158</identity> <target uri=\"sip:201@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 11:28 AM To: freeswitch-dev@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@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-de
v
-- 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-de
_______________________________________________ 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
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@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@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@cbeeton.com\"> <dialog id=\"d3d433ce-2324c33e@10.10.10.116\" call-id=\"d3d433ce-2324c33e@10.10.10.116\" local-tag=\"KQcQB9v3rmgpp\" remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> <state>confirmed</state> <local> <identity display=\"44\">sip:44@10.10.10.158</identity> <target uri=\"sip:44@10.10.10.158\"> <param pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local> <remote> <identity display=\"201-116\">sip:201@10.10.10.158</identity> <target uri=\"sip:201@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 11:28 AM To: freeswitch-dev@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@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-de
v
-- 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-de
_______________________________________________ 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
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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 1:47 PM To: freeswitch-dev@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@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@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@cbeeton.com\"> <dialog id=\"d3d433ce-2324c33e@10.10.10.116\" call-id=\"d3d433ce-2324c33e@10.10.10.116\" local-tag=\"KQcQB9v3rmgpp\" remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> <state>confirmed</state> <local> <identity display=\"44\">sip:44@10.10.10.158</identity> <target uri=\"sip:44@10.10.10.158\"> <param pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local> <remote> <identity display=\"201-116\">sip:201@10.10.10.158</identity> <target uri=\"sip:201@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 11:28 AM To: freeswitch-dev@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@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-de
v
-- 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-de
_______________________________________________ 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-de
v
-- 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-de
_______________________________________________ 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
in this case you could possibly branch off with a 2nd sql stmt when so configured in the presence_probe handler to do exactly what you want and select all the same columns On Tue, Oct 12, 2010 at 1:05 PM, Beeton, Carolyn (Carolyn) <cbeeton@avaya.com> wrote:
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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 1:47 PM To: freeswitch-dev@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@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@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@cbeeton.com\"> <dialog id=\"d3d433ce-2324c33e@10.10.10.116\" call-id=\"d3d433ce-2324c33e@10.10.10.116\" local-tag=\"KQcQB9v3rmgpp\" remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> <state>confirmed</state> <local> <identity display=\"44\">sip:44@10.10.10.158</identity> <target uri=\"sip:44@10.10.10.158\"> <param pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local> <remote> <identity display=\"201-116\">sip:201@10.10.10.158</identity> <target uri=\"sip:201@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Tuesday, October 12, 2010 11:28 AM To: freeswitch-dev@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@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-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@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-de
_______________________________________________ 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-de
v
-- 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-de
_______________________________________________ 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
I've attached a patch which shows what I am thinking of. It adds two columns into the sip_dialogs table, to track to_tag and from_tag. Since one of the tags is sometimes not known when the dialog is created, it is updated on the 200 response (there is probably a better place to do this). Then when a NOTIFY(dialog) is being crafted, the call_id and tags and the remote contact uri are used. These fields and the remote target uri are important because they allow an INVITE with REPLACES to be crafted.
I am still not sure I understand the role of the sip_registrations table when crafting dialog events. I have reworked the query in a way which seems to me to match what the rfc describes.
Please let me know what you think of this patch. Is there a set of presence tests that can be run to ensure that existing behaviour is not adversely affected? I know the contents of the <dialog> element are still not 100% correct (for example, in the case where the call has come in from another domain, the remote identity uses the wrong domain. This doesn't cause me a problem but really it should be correct).
Thanks,
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 2:28 PM
> To: freeswitch-dev@lists.freeswitch.org
> Subject: Re: [Freeswitch-dev] Dialog events
>
> in this case you could possibly branch off with a 2nd sql
> stmt when so configured in the presence_probe handler to do
> exactly what you want and select all the same columns
>
> On Tue, Oct 12, 2010 at 1:05 PM, Beeton, Carolyn (Carolyn)
> <cbeeton@avaya.com> wrote:
> > 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@lists.freeswitch.org
> >> [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of
> >> Anthony Minessale
> >> Sent: Tuesday, October 12, 2010 1:47 PM
> >> To: freeswitch-dev@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@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@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@cbeeton.com\"> <dialog
> >> > id=\"d3d433ce-2324c33e@10.10.10.116\"
> >> > call-id=\"d3d433ce-2324c33e@10.10.10.116\"
> >> local-tag=\"KQcQB9v3rmgpp\"
> >> > remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\">
> >> > <state>confirmed</state> <local> <identity
> >> > display=\"44\">sip:44@10.10.10.158</identity>
> >> > <target uri=\"sip:44@10.10.10.158\"> <param
> >> > pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local>
> >> > <remote> <identity
> >> display=\"201-116\">sip:201@10.10.10.158</identity>
> >> > <target uri=\"sip:201@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@lists.freeswitch.org
> >> >> [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On
> Behalf Of
> >> >> Anthony Minessale
> >> >> Sent: Tuesday, October 12, 2010 11:28 AM
> >> >> To: freeswitch-dev@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@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-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@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-de
> >> >> >> v
> >> >> >> 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-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@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-de
> >> >> v
> >> >> 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-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@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-de
> >> v
> >> 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
>
> _______________________________________________
> 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
>
participants (2)
-
Anthony Minessale
-
Beeton, Carolyn (Carolyn)