Re: [Freeswitch-users] Terminating calls prior to answer using api
No joy, even using the "picked_off" cause I'm still getting a tone back indicating the call failed to connect. I have managed to hack a solution together using an idea from one of the previous suggestions. I'm sending a uuid_answer followed by a uuid_kill event on a timer half a second later. Obviously this isn't ideal as it gives me channel_answer events etc and timed events are rarely a good thing. Is the SIP notify route out of the question? I know next to nothing about SIP (but I'm enjoying the learning curve!) I'm using a Polycom IP335 it that helps. On Mon, Feb 11, 2013 at 9:39 PM, < freeswitch-users-request@lists.freeswitch.org> wrote:
Send FreeSWITCH-users mailing list submissions to freeswitch-users@lists.freeswitch.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeswitch.org/mailman/listinfo/freeswitch-users or, via email, send a message with subject or body 'help' to freeswitch-users-request@lists.freeswitch.org
You can reach the person managing the list at freeswitch-users-owner@lists.freeswitch.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of FreeSWITCH-users digest..."
Today's Topics:
1. Re: Terminating calls prior to answer using api (Anthony Minessale)
---------- Forwarded message ---------- From: Anthony Minessale <anthony.minessale@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 15:38:40 -0600 Subject: Re: [Freeswitch-users] Terminating calls prior to answer using api Oh, and remember to take the "SWITCH_CAUSE" out when using it with uuid_kill
uuid_kill <uuid> picked_off
On Mon, Feb 11, 2013 at 3:37 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Try SWITCH_CAUSE_PICKED_OFF or SWITCH_CAUSE_LOSE_RACE that will inject headers to the phone telling it that the call was completed elsewhere which makes most of them skip counting it as an error.
On Mon, Feb 11, 2013 at 2:07 PM, Steven Ayre <steveayre@gmail.com> wrote:
NOTIFY messages are a SIP feature outside of an INVITE call flow. Ending the call using 200+BYE, 4xx, 5xx or 6xx are your only options I'm afraid.
I'm writing a CTI application so terminating the call via the api prior
to answer without errors is really important.
Any call that's unanswered is a failed call, but that's not necessarily an error (eg user busy).
I understand your concern that the caller might not know if their call succeeded or not... Is there any possibility perhaps to answer the call, send it to a playback (eg 'your request was successful') and then hangup?
-Steve
On 11 February 2013 18:37, Gary Foreman <gaz.foreman@gmail.com> wrote:
I was concerned that might be the case, I have managed to get different errors by send alternative hangup codes "user_busy" for example is recognised but as you say all are still errors.
I'm planning on using Polycom sip phones, does anyone know if it is possible to end an unanswered call using a notify message or something? Like the talk sip notify message used to answer.
I'm writing a CTI application so terminating the call via the api prior to answer without errors is really important.
Thanks again
On Mon, Feb 11, 2013 at 6:07 PM, < freeswitch-users-request@lists.freeswitch.org> wrote:
Send FreeSWITCH-users mailing list submissions to freeswitch-users@lists.freeswitch.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeswitch.org/mailman/listinfo/freeswitch-users or, via email, send a message with subject or body 'help' to freeswitch-users-request@lists.freeswitch.org
You can reach the person managing the list at freeswitch-users-owner@lists.freeswitch.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of FreeSWITCH-users digest..."
Today's Topics:
1. Re: Throttle Error (Avi Marcus) 2. Re: Terminating calls prior to answer using api (Steven Ayre) 3. Re: Terminating calls prior to answer using api (Steven Ayre) 4. High Availability Cluster Module for FreeSWITCH - Major News Update (Eliot Gable) 5. Re: High Availability Cluster Module for FreeSWITCH (Luis Daniel Lucio Quiroz)
---------- Forwarded message ---------- From: Avi Marcus <avi@avimarcus.net> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 19:09:33 +0200 Subject: Re: [Freeswitch-users] Throttle Error
As Ken's original message said, try "fsctl sps 40" or the like. He said that otherwise only a restart, not reload xml would work.
-Avi (This message was painstakingly thumbed out on my mobile, so apologies for brevity and errors.)
On Feb 11, 2013 6:57 PM, "Archana Venugopan" <a.venugopan@mundio.com> wrote:
Hi,****
** **
When I gave fsctl sps it shows still 10. Can you please tell me apart from reload_xml do we have to anyother thing after changing switch.conf.xml? ****
** **
Regards,****
Archana****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Archana Venugopan *Sent:* 11 February 2013 16:37
To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Throttle Error
Ya i did re-loaded the xml. And this is what I see in status
UP 0 years, 6 days, 9 hours, 3...
_________________________________________________________________________ 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
---------- Forwarded message ---------- From: Steven Ayre <steveayre@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 17:40:57 +0000 Subject: Re: [Freeswitch-users] Terminating calls prior to answer using api You either answer a call with 200, redirect with 3xx, or give an error 4xx 5xx or 6xx... basically without answering your only option is to return an error.
The specific error code can show a varying number of levels of 'error' though. Some might be a perfectly valid result (eg 486 User Busy) while other's imply a more serious error (eg 500 Server Internal Error). But there's not really one for a successful unanswered call.
How your phone behaves on the various errors is really up to the SIP client though. A generic unable to connect message doesn't sound very useful, I'd expect different error tones depending on the response code.
-Steve
On 11 February 2013 15:30, Gary Foreman <gaz.foreman@gmail.com> wrote:
Hi,
I'm having an issue gracefully terminating calls prior to them being answered.
When I issue the uuid_kill command prior to the call being answered my sip client gives an error "unable to connect" with an error tone.
Is it possible to cancel the client dial without causing an error? Maybe using a sip notify message or something?
I can't seem to find a list of valid sip notify messages anywhere.
Thanks
_________________________________________________________________________ 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
---------- Forwarded message ---------- From: Steven Ayre <steveayre@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 17:42:51 +0000 Subject: Re: [Freeswitch-users] Terminating calls prior to answer using api The NORMAL_CLEARING ISDN clearing cause (16) has no mapping to any SIP code for example, it's a code you normally would only see a) when the caller hangs up at any time (regardless of answered or not) or b) when call has been answered *then* callee hangs up.
-Steve
On 11 February 2013 17:40, Steven Ayre <steveayre@gmail.com> wrote:
You either answer a call with 200, redirect with 3xx, or give an error 4xx 5xx or 6xx... basically without answering your only option is to return an error.
The specific error code can show a varying number of levels of 'error' though. Some might be a perfectly valid result (eg 486 User Busy) while other's imply a more serious error (eg 500 Server Internal Error). But there's not really one for a successful unanswered call.
How your phone behaves on the various errors is really up to the SIP client though. A generic unable to connect message doesn't sound very useful, I'd expect different error tones depending on the response code.
-Steve
On 11 February 2013 15:30, Gary Foreman <gaz.foreman@gmail.com>wrote:
> Hi, > > I'm having an issue gracefully terminating calls prior to them being > answered. > > When I issue the uuid_kill command prior to the call being answered > my sip client gives an error "unable to connect" with an error tone. > > Is it possible to cancel the client dial without causing an error? > Maybe using a sip notify message or something? > > I can't seem to find a list of valid sip notify messages anywhere. > > Thanks > > > _________________________________________________________________________ > 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 > >
---------- Forwarded message ---------- From: Eliot Gable <egable+freeswitch@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 12:44:55 -0500 Subject: [Freeswitch-users] High Availability Cluster Module for FreeSWITCH - Major News Update After discussing this project in further detail with Tony, I have decided to cancel the Kickstarter project. Funding will now go through FreeSWITCH Solutions. If you would like to contribute towards making mod_ha_cluster a reality, please send contributions to FreeSWITCH Solutions.
Thanks!
-- Eliot Gable
---------- Forwarded message ---------- From: Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 13:06:16 -0500 Subject: Re: [Freeswitch-users] High Availability Cluster Module for FreeSWITCH Is the latest snapshot ofyour module at git://git.freeswitch.org/freeswitch-contrib.git ?
2013/2/11 Eliot Gable <egable+freeswitch@gmail.com>:
On Mon, Feb 11, 2013 at 7:36 AM, Marcin Gozdalik <gozdal@gmail.com> wrote: > > +1 > > I do not doubt mod_ha is necessary inside of FS and it may be > better/simpler than writing Pacemaker resource agent, but writing > yet-another-cluster-communication-engine is IMHO the wrong way to go > and using Corosync for communication will give a lot of value from > mature codebase. >
I understand what you are saying, but what I am trying to get across is that I am not writing yet-another-cluster-communication-engine. All I am really doing is combining a multicast messaging API written by Tony and the event API in FS to broadcast existing state information between multiple FS nodes, as well as adding a tiny amount of logic on top of that to coordinate call fail over and recovery. That's probably a little over-simplified, but it gets the point across. The network communication code is already in FS and well tested. The event system is already in FS and well tested. I have already written the code to the point that it parses the configuration files and starts sending heartbeats out all of the interfaces configured. I have also already written a lot of the code that deals with the state transitions. All I am talking about doing is implementing a tiny little finite state machine. It's a pretty trivial programming task. In fact, I think it was covered in my first year at Carnegie Mellon University. Of course, I had already figured out how to write such things in high school, I just did not know what it was called at that point. My point is, that this is not yet-another-cluster-communication-engine. It is a very specific and small finite state machine designed solely with the goal in mind of making FS have just enough information to coordinate call fail over internally. If I recall correctly, a lot of people also said writing yet-another-VoIP-server was a waste of time, but now we have FreeSWITCH, and it was obviously worth the effort. And I am not even trying to do something as complex as that. If you think this is yet-another-cluster-communication-engine, you are missing the point. It is not. It never will be.
Look at Sonus, Genband, Broadsoft, Veraz, etc. All the big-name carrier-grade telecom providers have a built-in solution for automatic call fail over. The only way FreeSWITCH will ever compete with such solutions is if it also has that feature. Pacemaker and Corosync are overkill just to get FS to handle single node failures and provide call recovery. It took me a full 3 months of working with them every day to really understand how to deploy them properly in conjunction with FreeSWITCH and Postgres to provide a carrier-grade hot-standby solution which was robust enough to handle 99% of the failures I could throw at it. Granted, this was back when the configuration still needed to be written by hand in XML and prior the existence of any resource agent for FreeSWITCH. But, even with those changes, deploying Pacemaker and Corosync is not a simple task. If that is the requirement for FS to have HA, it will never truly stand a chance against commercial offerings.
_________________________________________________________________________
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
_______________________________________________
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
_________________________________________________________________________ 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
-- 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-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
As I said, another option is a uuid_transfer to a dialplan extension that does the answer then hangup. That way you only need one command. If you don't want to see a CDR at all (but you usually get one even if the call doesn't connect) you can set process_cdr<http://wiki.freeswitch.org/wiki/Variable_process_cdr> =false. Why are you concerned about channel_answer events? Don't listen / ignore it. -Avi
What version of the Polycom firmware? Also, I think you have to tell the phone to support the "call answered elsewhere" feature. I don't know it off the top of my head so google around for that. We do this all the time on the CudaTel so I know it is possible. (I just am not an expert in the nitty gritty details...) -MC On Mon, Feb 11, 2013 at 3:03 PM, Gary Foreman <gaz.foreman@gmail.com> wrote:
No joy, even using the "picked_off" cause I'm still getting a tone back indicating the call failed to connect.
I have managed to hack a solution together using an idea from one of the previous suggestions. I'm sending a uuid_answer followed by a uuid_kill event on a timer half a second later.
Obviously this isn't ideal as it gives me channel_answer events etc and timed events are rarely a good thing.
Is the SIP notify route out of the question? I know next to nothing about SIP (but I'm enjoying the learning curve!)
I'm using a Polycom IP335 it that helps.
On Mon, Feb 11, 2013 at 9:39 PM, < freeswitch-users-request@lists.freeswitch.org> wrote:
Send FreeSWITCH-users mailing list submissions to freeswitch-users@lists.freeswitch.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeswitch.org/mailman/listinfo/freeswitch-users or, via email, send a message with subject or body 'help' to freeswitch-users-request@lists.freeswitch.org
You can reach the person managing the list at freeswitch-users-owner@lists.freeswitch.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of FreeSWITCH-users digest..."
Today's Topics:
1. Re: Terminating calls prior to answer using api (Anthony Minessale)
---------- Forwarded message ---------- From: Anthony Minessale <anthony.minessale@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 15:38:40 -0600 Subject: Re: [Freeswitch-users] Terminating calls prior to answer using api Oh, and remember to take the "SWITCH_CAUSE" out when using it with uuid_kill
uuid_kill <uuid> picked_off
On Mon, Feb 11, 2013 at 3:37 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Try SWITCH_CAUSE_PICKED_OFF or SWITCH_CAUSE_LOSE_RACE that will inject headers to the phone telling it that the call was completed elsewhere which makes most of them skip counting it as an error.
On Mon, Feb 11, 2013 at 2:07 PM, Steven Ayre <steveayre@gmail.com>wrote:
NOTIFY messages are a SIP feature outside of an INVITE call flow. Ending the call using 200+BYE, 4xx, 5xx or 6xx are your only options I'm afraid.
I'm writing a CTI application so terminating the call via the api prior
to answer without errors is really important.
Any call that's unanswered is a failed call, but that's not necessarily an error (eg user busy).
I understand your concern that the caller might not know if their call succeeded or not... Is there any possibility perhaps to answer the call, send it to a playback (eg 'your request was successful') and then hangup?
-Steve
On 11 February 2013 18:37, Gary Foreman <gaz.foreman@gmail.com> wrote:
I was concerned that might be the case, I have managed to get different errors by send alternative hangup codes "user_busy" for example is recognised but as you say all are still errors.
I'm planning on using Polycom sip phones, does anyone know if it is possible to end an unanswered call using a notify message or something? Like the talk sip notify message used to answer.
I'm writing a CTI application so terminating the call via the api prior to answer without errors is really important.
Thanks again
On Mon, Feb 11, 2013 at 6:07 PM, < freeswitch-users-request@lists.freeswitch.org> wrote:
Send FreeSWITCH-users mailing list submissions to freeswitch-users@lists.freeswitch.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeswitch.org/mailman/listinfo/freeswitch-users or, via email, send a message with subject or body 'help' to freeswitch-users-request@lists.freeswitch.org
You can reach the person managing the list at freeswitch-users-owner@lists.freeswitch.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of FreeSWITCH-users digest..."
Today's Topics:
1. Re: Throttle Error (Avi Marcus) 2. Re: Terminating calls prior to answer using api (Steven Ayre) 3. Re: Terminating calls prior to answer using api (Steven Ayre) 4. High Availability Cluster Module for FreeSWITCH - Major News Update (Eliot Gable) 5. Re: High Availability Cluster Module for FreeSWITCH (Luis Daniel Lucio Quiroz)
---------- Forwarded message ---------- From: Avi Marcus <avi@avimarcus.net> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 19:09:33 +0200 Subject: Re: [Freeswitch-users] Throttle Error
As Ken's original message said, try "fsctl sps 40" or the like. He said that otherwise only a restart, not reload xml would work.
-Avi (This message was painstakingly thumbed out on my mobile, so apologies for brevity and errors.)
On Feb 11, 2013 6:57 PM, "Archana Venugopan" <a.venugopan@mundio.com> wrote:
Hi,****
** **
When I gave fsctl sps it shows still 10. Can you please tell me apart from reload_xml do we have to anyother thing after changing switch.conf.xml? ****
** **
Regards,****
Archana****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Archana Venugopan *Sent:* 11 February 2013 16:37
To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Throttle Error
Ya i did re-loaded the xml. And this is what I see in status
UP 0 years, 6 days, 9 hours, 3...
_________________________________________________________________________ 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
---------- Forwarded message ---------- From: Steven Ayre <steveayre@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 17:40:57 +0000 Subject: Re: [Freeswitch-users] Terminating calls prior to answer using api You either answer a call with 200, redirect with 3xx, or give an error 4xx 5xx or 6xx... basically without answering your only option is to return an error.
The specific error code can show a varying number of levels of 'error' though. Some might be a perfectly valid result (eg 486 User Busy) while other's imply a more serious error (eg 500 Server Internal Error). But there's not really one for a successful unanswered call.
How your phone behaves on the various errors is really up to the SIP client though. A generic unable to connect message doesn't sound very useful, I'd expect different error tones depending on the response code.
-Steve
On 11 February 2013 15:30, Gary Foreman <gaz.foreman@gmail.com>wrote:
> Hi, > > I'm having an issue gracefully terminating calls prior to them being > answered. > > When I issue the uuid_kill command prior to the call being answered > my sip client gives an error "unable to connect" with an error tone. > > Is it possible to cancel the client dial without causing an error? > Maybe using a sip notify message or something? > > I can't seem to find a list of valid sip notify messages anywhere. > > Thanks > > > _________________________________________________________________________ > 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 > >
---------- Forwarded message ---------- From: Steven Ayre <steveayre@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 17:42:51 +0000 Subject: Re: [Freeswitch-users] Terminating calls prior to answer using api The NORMAL_CLEARING ISDN clearing cause (16) has no mapping to any SIP code for example, it's a code you normally would only see a) when the caller hangs up at any time (regardless of answered or not) or b) when call has been answered *then* callee hangs up.
-Steve
On 11 February 2013 17:40, Steven Ayre <steveayre@gmail.com> wrote:
> You either answer a call with 200, redirect with 3xx, or give an > error 4xx 5xx or 6xx... basically without answering your only option is to > return an error. > > The specific error code can show a varying number of levels of > 'error' though. Some might be a perfectly valid result (eg 486 User Busy) > while other's imply a more serious error (eg 500 Server Internal Error). > But there's not really one for a successful unanswered call. > > How your phone behaves on the various errors is really up to the SIP > client though. A generic unable to connect message doesn't sound very > useful, I'd expect different error tones depending on the response code. > > -Steve > > > > On 11 February 2013 15:30, Gary Foreman <gaz.foreman@gmail.com>wrote: > >> Hi, >> >> I'm having an issue gracefully terminating calls prior to them >> being answered. >> >> When I issue the uuid_kill command prior to the call being answered >> my sip client gives an error "unable to connect" with an error tone. >> >> Is it possible to cancel the client dial without causing an error? >> Maybe using a sip notify message or something? >> >> I can't seem to find a list of valid sip notify messages anywhere. >> >> Thanks >> >> >> _________________________________________________________________________ >> 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 >> >> >
---------- Forwarded message ---------- From: Eliot Gable <egable+freeswitch@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 12:44:55 -0500 Subject: [Freeswitch-users] High Availability Cluster Module for FreeSWITCH - Major News Update After discussing this project in further detail with Tony, I have decided to cancel the Kickstarter project. Funding will now go through FreeSWITCH Solutions. If you would like to contribute towards making mod_ha_cluster a reality, please send contributions to FreeSWITCH Solutions.
Thanks!
-- Eliot Gable
---------- Forwarded message ---------- From: Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Cc: Date: Mon, 11 Feb 2013 13:06:16 -0500 Subject: Re: [Freeswitch-users] High Availability Cluster Module for FreeSWITCH Is the latest snapshot ofyour module at git://git.freeswitch.org/freeswitch-contrib.git ?
2013/2/11 Eliot Gable <egable+freeswitch@gmail.com>: > On Mon, Feb 11, 2013 at 7:36 AM, Marcin Gozdalik <gozdal@gmail.com> wrote: >> >> +1 >> >> I do not doubt mod_ha is necessary inside of FS and it may be >> better/simpler than writing Pacemaker resource agent, but writing >> yet-another-cluster-communication-engine is IMHO the wrong way to go >> and using Corosync for communication will give a lot of value from >> mature codebase. >> > > I understand what you are saying, but what I am trying to get across is that > I am not writing yet-another-cluster-communication-engine. All I am really > doing is combining a multicast messaging API written by Tony and the event > API in FS to broadcast existing state information between multiple FS nodes, > as well as adding a tiny amount of logic on top of that to coordinate call > fail over and recovery. That's probably a little over-simplified, but it > gets the point across. The network communication code is already in FS and > well tested. The event system is already in FS and well tested. I have > already written the code to the point that it parses the configuration files > and starts sending heartbeats out all of the interfaces configured. I have > also already written a lot of the code that deals with the state > transitions. All I am talking about doing is implementing a tiny little > finite state machine. It's a pretty trivial programming task. In fact, I > think it was covered in my first year at Carnegie Mellon University. Of > course, I had already figured out how to write such things in high school, I > just did not know what it was called at that point. My point is, that this > is not yet-another-cluster-communication-engine. It is a very specific and > small finite state machine designed solely with the goal in mind of making > FS have just enough information to coordinate call fail over internally. If > I recall correctly, a lot of people also said writing > yet-another-VoIP-server was a waste of time, but now we have FreeSWITCH, and > it was obviously worth the effort. And I am not even trying to do something > as complex as that. If you think this is > yet-another-cluster-communication-engine, you are missing the point. It is > not. It never will be. > > Look at Sonus, Genband, Broadsoft, Veraz, etc. All the big-name > carrier-grade telecom providers have a built-in solution for automatic call > fail over. The only way FreeSWITCH will ever compete with such solutions is > if it also has that feature. Pacemaker and Corosync are overkill just to get > FS to handle single node failures and provide call recovery. It took me a > full 3 months of working with them every day to really understand how to > deploy them properly in conjunction with FreeSWITCH and Postgres to provide > a carrier-grade hot-standby solution which was robust enough to handle 99% > of the failures I could throw at it. Granted, this was back when the > configuration still needed to be written by hand in XML and prior the > existence of any resource agent for FreeSWITCH. But, even with those > changes, deploying Pacemaker and Corosync is not a simple task. If that is > the requirement for FS to have HA, it will never truly stand a chance > against commercial offerings.
> > > > _________________________________________________________________________ > 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 >
_______________________________________________
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
_________________________________________________________________________ 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
-- 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-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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
participants (3)
-
Avi Marcus
-
Gary Foreman
-
Michael Collins