and

The result is the same: a.b.c.d does not reply anything, so after 5 seconds, provider.out is tried, but then, INVITEs are still sent to a.b.c.d

I actually think I understand why.

I think it's because those INVITE retries are happening within Sofia.

FreeSWITCH does not have a reply at all, so leg-timeout or leg_progress_timeout are still triggered, and the dialplan continues, but Sofia is still doing its retries on the first target.

I guess to avoid this, we would need a way to control the number of retries sent by Sofia.

It's probably not a big deal anyway for my situation, where i want to send calls to backup numbers when the trunk to a.b.c.d is really dead.

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 03/02/2011 à 23:02, Anthony Minessale a écrit :

We do not have anything to timeout at a 100 the only thing we can do
is 180 or 183 using [leg_progress_timeout=X] in front of each leg.

On Thu, Feb 3, 2011 at 3:54 PM, David Ponzone <david.ponzone@ipeva.fr> wrote:
It's my time to mess with XXX_timeout variables in FreeSWITCH.
What I need to do is to route a call to a gateway, and if I don't have an
answer (like not even the 100) within X seconds, I try to route the call to
a backup number.
I tried it this way:
   <extension name="gw_then_backup">
   <condition field="destination_number" expression="^(XXXXXXXXXX)$">
   <action application="bridge"
data="{leg_timeout=5}sofia/external/$1@a.b.c.d|sofia/gateway/provider.out/YYYYYYYYYY"/>
   </condition>
   </extension>
My understanding was that a.b.c.d would be tried for 5 seconds, and if no
100 is received, gateway provider.out would then be used.
It works...but after the first INVITE to provider.out (which sends back
100/180/183), I can see some more INVITEs sent to a.b.c.d.
I am wondering if I am doing something wrong, or if there is an issue.
I use latest git from 5 minutes ago.
Thanks
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.

_______________________________________________
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

_______________________________________________
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