continue_on_fail for condition only where 100 not received?
Hi, I can't seem to get a continue_on_fail code which would only retry if no response whatsoever is received from an endpoint. Does anyone know how I could route to a secondary endpoint ONLY if the initial endpoint does not respond with 100? I guess as a secondary part of the question I would need to know if I can change the INVITE timer to a smaller amount so the second device is attempted in less than 60 seconds. Basically I have a bunch of routing devices within the network I want to route to with a failove option, these devices onward route so I trust if that device is OK not to route to the second device, given these devices log sessions themselves it's vital that if one device receives an INVITE none of the others do for the same session. Thanks, Neil. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/continue-on-fail-for-condition... Sent from the freeswitch-users mailing list archive at Nabble.com.
That seems like rather weird request since the 100 trying isn't required. /b On Apr 20, 2011, at 1:32 PM, peely wrote:
Hi,
I can't seem to get a continue_on_fail code which would only retry if no response whatsoever is received from an endpoint.
Does anyone know how I could route to a secondary endpoint ONLY if the initial endpoint does not respond with 100? I guess as a secondary part of the question I would need to know if I can change the INVITE timer to a smaller amount so the second device is attempted in less than 60 seconds.
Basically I have a bunch of routing devices within the network I want to route to with a failove option, these devices onward route so I trust if that device is OK not to route to the second device, given these devices log sessions themselves it's vital that if one device receives an INVITE none of the others do for the same session.
Thanks,
Neil.
When using UDP it's typically a good idea to fire some kind of provisional response ASAP to prevent the SIP retransmission timers from freaking out and repeatedly resending the initial INVITE. That's where 100 Trying comes in. On Thu, Apr 21, 2011 at 10:13 AM, Brian West <brian@freeswitch.org> wrote:
That seems like rather weird request since the 100 trying isn't required.
/b
-- Kristian Kielhofner
Yes, but it can be skipped - for instance if you're autoanswering you could skip the 100 and jump straight to the 200. Or similarly if you're generating ringback jump straight to the 183. There's no reason that 100 is needed first. -Steve On 21 April 2011 15:31, Kristian Kielhofner <kris@kriskinc.com> wrote:
When using UDP it's typically a good idea to fire some kind of provisional response ASAP to prevent the SIP retransmission timers from freaking out and repeatedly resending the initial INVITE. That's where 100 Trying comes in.
On Thu, Apr 21, 2011 at 10:13 AM, Brian West <brian@freeswitch.org> wrote:
That seems like rather weird request since the 100 trying isn't required.
/b
-- Kristian Kielhofner
_______________________________________________ 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
So *relying* on a 100 Trying is dangerous, but keeping an eye out for it is okay. To the OP (Neil) I'd ask: what is the failure condition when a 100 Trying does not come back? Is that a form of "gateway down"? Is it possibly to use SIP OPTIONS to test this instead of relying upon a 100? -MC On Thu, Apr 21, 2011 at 8:55 AM, Steven Ayre <steveayre@gmail.com> wrote:
Yes, but it can be skipped - for instance if you're autoanswering you could skip the 100 and jump straight to the 200. Or similarly if you're generating ringback jump straight to the 183. There's no reason that 100 is needed first.
-Steve
On 21 April 2011 15:31, Kristian Kielhofner <kris@kriskinc.com> wrote:
When using UDP it's typically a good idea to fire some kind of provisional response ASAP to prevent the SIP retransmission timers from freaking out and repeatedly resending the initial INVITE. That's where 100 Trying comes in.
On Thu, Apr 21, 2011 at 10:13 AM, Brian West <brian@freeswitch.org> wrote:
That seems like rather weird request since the 100 trying isn't required.
/b
-- Kristian Kielhofner
_______________________________________________ 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
Hi, I can guarantee a 100 as the equipment is within my network! In this condition I'm only concerned about a dead box scenario, in fact the boxes are configured as separate Gateways so I guess I could rely on the gateway being available through OPTIONS pings and being taken out of service automatically. So either a CONTINUE_ON_FAIL which acts on no 100 response within x seconds or will only attempt a second gateway if the first gateway is disabled would do. Any ideas? On the other topics, it's quite common for User Agents to offer an "always send 100 trying" option for this specific reason, although you need to know it is enabled I guess. Thanks, Neil. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/continue-on-fail-for-condition... Sent from the freeswitch-users mailing list archive at Nabble.com.
Well if you can rely on SIP OPTIONS, you should do that then :) You can easily check gateway status with: <condition field="${sofia profile external gwlist up}" expression="\bname_of_your_gateway\b"> </condition> David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 26/04/2011 à 17:50, peely a écrit :
Hi,
I can guarantee a 100 as the equipment is within my network!
In this condition I'm only concerned about a dead box scenario, in fact the boxes are configured as separate Gateways so I guess I could rely on the gateway being available through OPTIONS pings and being taken out of service automatically.
So either a CONTINUE_ON_FAIL which acts on no 100 response within x seconds or will only attempt a second gateway if the first gateway is disabled would do.
Any ideas?
On the other topics, it's quite common for User Agents to offer an "always send 100 trying" option for this specific reason, although you need to know it is enabled I guess.
Thanks,
Neil.
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/continue-on-fail-for-condition... Sent from the freeswitch-users mailing list archive at Nabble.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
Of course it can be skipped but nothing, and I mean nothing, can fire faster than a 100. To my knowledge Sofia fires a 100 before the dialplan even begins hunting, as an example (very good behavior). In cases where the far end has a low T1 timer you should fire a 100 before you even take the time to execute dialplan, etc. Especially in cases where you may encounter high call volume and varying call setup/hunting times. SER config 101 is to fire a 100 before you do any DB logic, etc as it buys you time beyond the first T1 timer (500ms or less) before the far end (that you have no control over) retries. It's best practice and HIGHLY, HIGHLY recommended. This is such a strange case I'm not sure what the best recommendation might be as the original question doesn't contain enough specific detail. On Thu, Apr 21, 2011 at 11:55 AM, Steven Ayre <steveayre@gmail.com> wrote:
Yes, but it can be skipped - for instance if you're autoanswering you could skip the 100 and jump straight to the 200. Or similarly if you're generating ringback jump straight to the 183. There's no reason that 100 is needed first.
-Steve
-- Kristian Kielhofner
I think the original question was: is there a way to failover if the remote gateway does not send back anything (no 1XX, no 2XX), with a configurable INVITE timeout (5 seconds would probably be better than 60). To answer to Mike: I think we should consider the possibility that the remote gateway answers correctly to SIP OPTIONS, but only fails to respond to INVITEs. I saw weirder things :) David Ponzone Direction Technique, email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 21/04/2011 à 20:06, Kristian Kielhofner a écrit :
Of course it can be skipped but nothing, and I mean nothing, can fire faster than a 100. To my knowledge Sofia fires a 100 before the dialplan even begins hunting, as an example (very good behavior). In cases where the far end has a low T1 timer you should fire a 100 before you even take the time to execute dialplan, etc. Especially in cases where you may encounter high call volume and varying call setup/hunting times.
SER config 101 is to fire a 100 before you do any DB logic, etc as it buys you time beyond the first T1 timer (500ms or less) before the far end (that you have no control over) retries. It's best practice and HIGHLY, HIGHLY recommended.
This is such a strange case I'm not sure what the best recommendation might be as the original question doesn't contain enough specific detail.
On Thu, Apr 21, 2011 at 11:55 AM, Steven Ayre <steveayre@gmail.com> wrote:
Yes, but it can be skipped - for instance if you're autoanswering you could skip the 100 and jump straight to the 200. Or similarly if you're generating ringback jump straight to the 183. There's no reason that 100 is needed first.
-Steve
-- Kristian Kielhofner
_______________________________________________ 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 (6)
-
Brian West
-
David Ponzone
-
Kristian Kielhofner
-
Michael Collins
-
peely
-
Steven Ayre