Monitoring Phone Endpoint Deregistration/Losing Connection
I'd like to monitor if my user's sip phones are disconnected, to let me know there might be a problem in advance. I see there's a CUSTOM event called sofia::unregister. I presume that triggers whenever a phone doesn't re-register in enough time. However, with default registation of 60 minutes (or even 10) I'd like more granularity. I have the endpoints pinging FS, but I don't see an event or that information stored anywhere. How about setting nat-options-ping (or better, all-reg-options-ping since most NATed endpoint don't actually self-identify). Do I get an event if that fails? I see unregister-on-options-fail but that seemed too aggressive when I tried that in the past. What exactly does the less sever mark-dead-on-options-fail do? Does it remove it from the user/$NUMBER endpoint? Does it trigger an event for me? Other suggestions? -Avi
My testing was disappointing... My script didn't catch any sofia::unregister events. It caught sofia::register, pre_register so it seems to be listening properly. Also, I'm pretty sure all-reg-options-ping was pinging, and I had mark-dead-on-options-fail set, but I didn't see anything different when looking at the REG list after unplugging an endpoint. I would imagine there should be an event there, but I don't know what it's called and it's really hard to find a lone event on a busy switch... Are these bugs? Or am I just missing something about how this works? -Avi Marcus On Wed, Feb 27, 2013 at 2:14 AM, Avi Marcus <avi@avimarcus.net> wrote:
I'd like to monitor if my user's sip phones are disconnected, to let me know there might be a problem in advance.
I see there's a CUSTOM event called sofia::unregister. I presume that triggers whenever a phone doesn't re-register in enough time.
However, with default registation of 60 minutes (or even 10) I'd like more granularity.
I have the endpoints pinging FS, but I don't see an event or that information stored anywhere.
How about setting nat-options-ping (or better, all-reg-options-ping since most NATed endpoint don't actually self-identify). Do I get an event if that fails? I see unregister-on-options-fail but that seemed too aggressive when I tried that in the past.
What exactly does the less sever mark-dead-on-options-fail do? Does it remove it from the user/$NUMBER endpoint? Does it trigger an event for me?
Other suggestions?
-Avi
Avi, Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.) I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server. If anyone else has been through this exercise we'd appreciate hearing from them. -MC On Thu, Feb 28, 2013 at 3:18 PM, Avi Marcus <avi@avimarcus.net> wrote:
My testing was disappointing... My script didn't catch any sofia::unregister events. It caught sofia::register, pre_register so it seems to be listening properly.
Also, I'm pretty sure all-reg-options-ping was pinging, and I had mark-dead-on-options-fail set, but I didn't see anything different when looking at the REG list after unplugging an endpoint. I would imagine there should be an event there, but I don't know what it's called and it's really hard to find a lone event on a busy switch...
Are these bugs? Or am I just missing something about how this works?
-Avi Marcus
On Wed, Feb 27, 2013 at 2:14 AM, Avi Marcus <avi@avimarcus.net> wrote:
I'd like to monitor if my user's sip phones are disconnected, to let me know there might be a problem in advance.
I see there's a CUSTOM event called sofia::unregister. I presume that triggers whenever a phone doesn't re-register in enough time.
However, with default registation of 60 minutes (or even 10) I'd like more granularity.
I have the endpoints pinging FS, but I don't see an event or that information stored anywhere.
How about setting nat-options-ping (or better, all-reg-options-ping since most NATed endpoint don't actually self-identify). Do I get an event if that fails? I see unregister-on-options-fail but that seemed too aggressive when I tried that in the past.
What exactly does the less sever mark-dead-on-options-fail do? Does it remove it from the user/$NUMBER endpoint? Does it trigger an event for me?
Other suggestions?
-Avi
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Yeah, I'll have to try on a quiet test system. You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught. -Avi On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org> wrote:
Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
-MC
On Thu, Feb 28, 2013 at 3:18 PM, Avi Marcus <avi@avimarcus.net> wrote:
My testing was disappointing... My script didn't catch any sofia::unregister events. It caught sofia::register, pre_register so it seems to be listening properly.
Also, I'm pretty sure all-reg-options-ping was pinging, and I had mark-dead-on-options-fail set, but I didn't see anything different when looking at the REG list after unplugging an endpoint. I would imagine there should be an event there, but I don't know what it's called and it's really hard to find a lone event on a busy switch...
Are these bugs? Or am I just missing something about how this works?
-Avi Marcus
On Wed, Feb 27, 2013 at 2:14 AM, Avi Marcus <avi@avimarcus.net> wrote:
I'd like to monitor if my user's sip phones are disconnected, to let me know there might be a problem in advance.
I see there's a CUSTOM event called sofia::unregister. I presume that triggers whenever a phone doesn't re-register in enough time.
However, with default registation of 60 minutes (or even 10) I'd like more granularity.
I have the endpoints pinging FS, but I don't see an event or that information stored anywhere.
How about setting nat-options-ping (or better, all-reg-options-ping since most NATed endpoint don't actually self-identify). Do I get an event if that fails? I see unregister-on-options-fail but that seemed too aggressive when I tried that in the past.
What exactly does the less sever mark-dead-on-options-fail do? Does it remove it from the user/$NUMBER endpoint? Does it trigger an event for me?
Other suggestions?
-Avi
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
If you waited for it to expire, it would have been re-registered, then you unplugged it, not giving it a chance to unregister? On Feb 28, 2013, at 8:23 PM, Avi Marcus <avi@avimarcus.net> wrote:
Yeah, I'll have to try on a quiet test system.
You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught.
-Avi
On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org> wrote: Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
Hmm Michael, that's right, it's not actually an unregister.. I want sofia::expire which does seem to work - yey! So now the question is how can I be notified even earlier, e.g. if sip options pinging isn't working? -Avi On Fri, Mar 1, 2013 at 5:44 PM, Michael Jerris <mike@jerris.com> wrote:
If you waited for it to expire, it would have been re-registered, then you unplugged it, not giving it a chance to unregister?
On Feb 28, 2013, at 8:23 PM, Avi Marcus <avi@avimarcus.net> wrote:
Yeah, I'll have to try on a quiet test system.
You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught.
-Avi
On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
look in the code to see if it fires an event when that happens or add one if not and submit a patch. On Sat, Mar 2, 2013 at 12:08 PM, Avi Marcus <avi@avimarcus.net> wrote:
Hmm Michael, that's right, it's not actually an unregister.. I want sofia::expire which does seem to work - yey!
So now the question is how can I be notified even earlier, e.g. if sip options pinging isn't working?
-Avi
On Fri, Mar 1, 2013 at 5:44 PM, Michael Jerris <mike@jerris.com> wrote:
If you waited for it to expire, it would have been re-registered, then you unplugged it, not giving it a chance to unregister?
On Feb 28, 2013, at 8:23 PM, Avi Marcus <avi@avimarcus.net> wrote:
Yeah, I'll have to try on a quiet test system.
You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught.
-Avi
On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users 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 well that's weird.. in the code base: git grep mark-dead-on-options-fail =>nothing. I found the other similar occurrence, unregister - it gets triggered in src/mod/endpoints/mod_sofia/sofia.c , line 4769 in head. } else if (sofia_test_pflag(profile, PFLAG_UNREG_OPTIONS_FAIL) I think some code needs to be reworked there to trigger an event even if the unregister flag isn't set. I'll have more time tomorrow to take a look and see if I have any clue what I'm doing. -Avi On Sun, Mar 3, 2013 at 12:48 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
look in the code to see if it fires an event when that happens or add one if not and submit a patch.
On Sat, Mar 2, 2013 at 12:08 PM, Avi Marcus <avi@avimarcus.net> wrote:
Hmm Michael, that's right, it's not actually an unregister.. I want sofia::expire which does seem to work - yey!
So now the question is how can I be notified even earlier, e.g. if sip options pinging isn't working?
-Avi
On Fri, Mar 1, 2013 at 5:44 PM, Michael Jerris <mike@jerris.com> wrote:
If you waited for it to expire, it would have been re-registered, then you unplugged it, not giving it a chance to unregister?
On Feb 28, 2013, at 8:23 PM, Avi Marcus <avi@avimarcus.net> wrote:
Yeah, I'll have to try on a quiet test system.
You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught.
-Avi
On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users 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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Why would you want an event on every timeout if it already re-registered? On Mar 2, 2013, at 6:47 PM, Avi Marcus <avi@avimarcus.net> wrote:
OK well that's weird.. in the code base: git grep mark-dead-on-options-fail =>nothing.
I found the other similar occurrence, unregister - it gets triggered in src/mod/endpoints/mod_sofia/sofia.c , line 4769 in head. } else if (sofia_test_pflag(profile, PFLAG_UNREG_OPTIONS_FAIL)
I think some code needs to be reworked there to trigger an event even if the unregister flag isn't set. I'll have more time tomorrow to take a look and see if I have any clue what I'm doing.
-Avi
On Sun, Mar 3, 2013 at 12:48 AM, Anthony Minessale <anthony.minessale@gmail.com> wrote: look in the code to see if it fires an event when that happens or add one if not and submit a patch.
On Sat, Mar 2, 2013 at 12:08 PM, Avi Marcus <avi@avimarcus.net> wrote: Hmm Michael, that's right, it's not actually an unregister.. I want sofia::expire which does seem to work - yey!
So now the question is how can I be notified even earlier, e.g. if sip options pinging isn't working?
-Avi
On Fri, Mar 1, 2013 at 5:44 PM, Michael Jerris <mike@jerris.com> wrote: If you waited for it to expire, it would have been re-registered, then you unplugged it, not giving it a chance to unregister?
On Feb 28, 2013, at 8:23 PM, Avi Marcus <avi@avimarcus.net> wrote:
Yeah, I'll have to try on a quiet test system.
You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught.
-Avi
On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org> wrote: Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
If the ping times out, then the fact that it's registered isn't very helpful -- the endpoint isn't actually reachable. I'll have to figure out what threshold to actually ACT on the timeouts, though. I tried unregister-on-options-fail in the past and that resulted in the following: endpoints lost 'net access for a moment, but since expiry was 1 hour, it didn't realize it needed to re-register for an hour... -Avi On Mon, Mar 4, 2013 at 4:11 PM, Michael Jerris <mike@jerris.com> wrote:
Why would you want an event on every timeout if it already re-registered?
On Mar 2, 2013, at 6:47 PM, Avi Marcus <avi@avimarcus.net> wrote:
OK well that's weird.. in the code base: git grep mark-dead-on-options-fail =>nothing.
I found the other similar occurrence, unregister - it gets triggered in src/mod/endpoints/mod_sofia/sofia.c , line 4769 in head. } else if (sofia_test_pflag(profile, PFLAG_UNREG_OPTIONS_FAIL)
I think some code needs to be reworked there to trigger an event even if the unregister flag isn't set. I'll have more time tomorrow to take a look and see if I have any clue what I'm doing.
-Avi
On Sun, Mar 3, 2013 at 12:48 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
look in the code to see if it fires an event when that happens or add one if not and submit a patch.
On Sat, Mar 2, 2013 at 12:08 PM, Avi Marcus <avi@avimarcus.net> wrote:
Hmm Michael, that's right, it's not actually an unregister.. I want sofia::expire which does seem to work - yey!
So now the question is how can I be notified even earlier, e.g. if sip options pinging isn't working?
-Avi
On Fri, Mar 1, 2013 at 5:44 PM, Michael Jerris <mike@jerris.com> wrote:
If you waited for it to expire, it would have been re-registered, then you unplugged it, not giving it a chance to unregister?
On Feb 28, 2013, at 8:23 PM, Avi Marcus <avi@avimarcus.net> wrote:
Yeah, I'll have to try on a quiet test system.
You should know me better than that ;) I didn't just unplug a box... I waited until it expired in just 300 seconds, then unplugged it, then took a break -- when I came back, I saw it was no longer in the reg list but there was no event that was caught.
-Avi
On Fri, Mar 1, 2013 at 3:08 AM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Thanks for digging into this. I suspect that it is really a thankless task. First thing I'd suggest is that you get FS running on a laptop or some old sandbox system and put just a single phone on it so that you can more easily focus on the relevant events. Second, if you just unplug a phone then there's no way it can send an "unregister" REGISTER message. (I believe that an "unregister" is really just a REGISTER with expires time of zero.)
I would have suspected that mark-dead-on-options-fail would have kicked in when the unplugged phone didn't respond. Without the detailed event logs it will be difficult to see what's going on, hence the recommendation for a simple test server.
If anyone else has been through this exercise we'd appreciate hearing from them.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Anthony Minessale
-
Avi Marcus
-
Michael Collins
-
Michael Jerris