302 redirects and continue_on_fail=true
I have an upstream provider that utilizes a load balancer that spits back 302 redirects with contact headers SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP xxx.xxx.xxx.xxx: 5080;rport=5080;branch=z9hG4bKB6peFDvXZ5S2F;received=xxx.xxx.xxx.xxx From: "test" <sip:xxxxxxxxxx@xxx.xxx.xxx.xxx>;tag=ByFF2244HHvmj To: <sip: 61xxxxxx920@yyy.yyy.yyy.yy1>;tag=1288540-274799759-385876096-3219999652 Call-ID: f6dc8d30-edd7-122c-c98e-000e7f301839 CSeq: 117820807 INVITE Contact: <sip:61xxxxxx920@yyy.yyy.yyy.yy1:5062> Server: MERA MVTS3G v.3.10.2-49-Release Content-Length: 0 in my dialplan I have multiple upstream suppliers in a failover setup so I setup some vars and sip headers then attempt the bridge. if it fails I then go on to do the same thing for a few other suppliers ( setup headers, attempt bridge ) so because of this I use continue_on_fail=true it appears Freeswitch sees the 302 as a temp failure and does not follow the redirect, and instead moves on to the next upstream and bridges there. ive read that I can selectively exclude temporary failures from continue_on_fail but im not sure thats exact enough for this situation. I do wish for continue_on_fail to ignore 302 moved temporarily but not ALL temporary failures ( for which there are probably many more causes ) any help would be greatly appreciated as Im not sure the best way to resolve this. Jay
You can set continue_on_fail to the major (or all) causes that you want to handle and don't include 302 in those so it will continue to execute the extension, for example: continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION,CALL_REJECTED,USER_NOT_REGISTERED You can know more about the hangup causes here: http://wiki.freeswitch.org/wiki/Hangup_causes Regards, Raul On Sat, 2009-07-18 at 13:49 +1000, Jay Binks wrote:
I have an upstream provider that utilizes a load balancer that spits back 302 redirects with contact headers
SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5080;rport=5080;branch=z9hG4bKB6peFDvXZ5S2F;received=xxx.xxx.xxx.xxx From: "test" <sip:xxxxxxxxxx@xxx.xxx.xxx.xxx>;tag=ByFF2244HHvmj To: <sip:61xxxxxx920@yyy.yyy.yyy.yy1>;tag=1288540-274799759-385876096-3219999652 Call-ID: f6dc8d30-edd7-122c-c98e-000e7f301839 CSeq: 117820807 INVITE Contact: <sip:61xxxxxx920@yyy.yyy.yyy.yy1:5062> Server: MERA MVTS3G v.3.10.2-49-Release Content-Length: 0
in my dialplan I have multiple upstream suppliers in a failover setup so I setup some vars and sip headers then attempt the bridge. if it fails I then go on to do the same thing for a few other suppliers ( setup headers, attempt bridge ) so because of this I use continue_on_fail=true
it appears Freeswitch sees the 302 as a temp failure and does not follow the redirect, and instead moves on to the next upstream and bridges there.
ive read that I can selectively exclude temporary failures from continue_on_fail but im not sure thats exact enough for this situation. I do wish for continue_on_fail to ignore 302 moved temporarily but not ALL temporary failures ( for which there are probably many more causes )
any help would be greatly appreciated as Im not sure the best way to resolve this.
Jay _______________________________________________ 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
Sure however my concern is that NORMAL_TEMPORARY_FAILURE is a generic failure and not only from 302 redirects. I'm not sure I'm game to do this, unless Im being completly paranoid which is possible. Can I get advice on this from a few Other users ? Jay On 19/07/2009, at 8:29 AM, Raul Fragoso <raul@etellicom.com> wrote:
You can set continue_on_fail to the major (or all) causes that you want to handle and don't include 302 in those so it will continue to execute the extension, for example: continue_on_fail= NORMAL_TEMPORARY_FAILURE, USER_BUSY, NO_ANSWER, TIMEOUT,NO_ROUTE_DESTINATION,CALL_REJECTED,USER_NOT_REGISTERED
You can know more about the hangup causes here: http://wiki.freeswitch.org/wiki/Hangup_causes
Regards,
Raul
On Sat, 2009-07-18 at 13:49 +1000, Jay Binks wrote:
I have an upstream provider that utilizes a load balancer that spits back 302 redirects with contact headers
SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP xxx.xxx.xxx.xxx: 5080;rport=5080;branch=z9hG4bKB6peFDvXZ5S2F;received=xxx.xxx.xxx.xxx From: "test" <sip:xxxxxxxxxx@xxx.xxx.xxx.xxx>;tag=ByFF2244HHvmj To: <sip:61xxxxxx920@yyy.yyy.yyy.yy1>;tag=1288540-274799759-385876096-3219999652 Call-ID: f6dc8d30-edd7-122c-c98e-000e7f301839 CSeq: 117820807 INVITE Contact: <sip:61xxxxxx920@yyy.yyy.yyy.yy1:5062> Server: MERA MVTS3G v.3.10.2-49-Release Content-Length: 0
in my dialplan I have multiple upstream suppliers in a failover setup so I setup some vars and sip headers then attempt the bridge. if it fails I then go on to do the same thing for a few other suppliers ( setup headers, attempt bridge ) so because of this I use continue_on_fail=true
it appears Freeswitch sees the 302 as a temp failure and does not follow the redirect, and instead moves on to the next upstream and bridges there.
ive read that I can selectively exclude temporary failures from continue_on_fail but im not sure thats exact enough for this situation. I do wish for continue_on_fail to ignore 302 moved temporarily but not ALL temporary failures ( for which there are probably many more causes )
any help would be greatly appreciated as Im not sure the best way to resolve this.
Jay _______________________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I want to use bgdial command to add a person to a already started conference (that is, call that person and when answered - add the channel to conference). The scenario is I have two sip clients registered in default context - 1000 and 1001. 1000 dials conference number (3001 in this case) and new conference is started. I want to dial out to second using bgdial, unfortunately mod_sofia drops the call with 'Cannot Blind Transfer 1 Legged calls' message. Should I use the bgdial command differently? Or perhaps I should do this totally differently? Logs attached below. Thanks for any help, Lukasz freeswitch@Zwierko-laptop> conference list API CALL [conference(list)] output: Conference 3001-192.168.0.1 (1 member) 3;sofia/internal/1000@192.168.0.1;25f125a5-3556-a449-85ec-e4001336f313;1000;1000;hear|speak|floor;0;0;300 freeswitch@Zwierko-laptop> conference 3001-192.168.0.1 bgdial sofia/default/1001@192.168.0.1 API CALL [conference(3001-192.168.0.1 bgdial sofia/default/1001@192.168.0.1)] output: OK freeswitch@Zwierko-laptop> 2009-07-19 13:19:44.451100 [NOTICE] switch_channel.c:602 New Channel sofia/internal/1001@192.168.0.1 [b9fada7f-9c1d-4949-af8a-a8220ce f9c5b] 2009-07-19 13:19:44.459100 [NOTICE] switch_channel.c:602 New Channel sofia/internal/48228882211@192.168.0.1 [4f6b26dd-a0cb-2846-ad17-5f517e60e2e7] 2009-07-19 13:19:44.488100 [INFO] mod_dialplan_xml.c:252 Processing TelkaSwitch->1001 in context public 2009-07-19 13:19:44.495100 [ERR] sofia.c:4174 Cannot Blind Transfer 1 Legged calls 2009-07-19 13:19:44.498100 [NOTICE] sofia.c:3775 Hangup sofia/internal/1001@192.168.0.1 [CS_CONSUME_MEDIA] [NO_USER_RESPONSE] 2009-07-19 13:19:44.501100 [ERR] mod_conference.c:4351 Cannot create outgoing channel, cause: NO_USER_RESPONSE 2009-07-19 13:19:44.512100 [NOTICE] switch_core_session.c:1085 Session 9 (sofia/internal/1001@192.168.0.1) Ended 2009-07-19 13:19:44.512100 [NOTICE] switch_core_session.c:1087 Close Channel sofia/internal/1001@192.168.0.1 [CS_DESTROY] 2009-07-19 13:19:44.628100 [NOTICE] switch_core_state_machine.c:179 Hangup sofia/internal/48228882211@192.168.0.1 [CS_EXECUTE] [NORMAL_CLEARING] 2009-07-19 13:19:44.708100 [NOTICE] switch_core_session.c:1085 Session 10 (sofia/internal/48228882211@192.168.0.1) Ended 2009-07-19 13:19:44.708100 [NOTICE] switch_core_session.c:1087 Close Channel sofia/internal/48228882211@192.168.0.1 [CS_DESTROY] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKYwMRAAoJED7LBosr0F2ullAH/j6AebaezM2/RQ4PVKeNbMEm yWYqC1bDmp5F56owRH6Vq7BRnXKB4roqV2NLFqLNRYwzq/S4bzc9p417/NckrACg DhmZ6tFd4ujLb6B1HvJMTKsDvnYCpn5EVCbENfKVIY4INDAcEYbncwUA21XxILI+ ztz+6qNPwOMOjY9aZaf1qpTcTcG2yn62mpvesmVeYS1vNpZFVpnQq4PrukDg+1xs N8EpJetP0FxhYzT/IiD9fS2wAzQSgJPgo0m7R4ezk/1NIF9f+o0irgc8zx+VgKw1 UhJ1FLhs8ObzhYclvwJxwTlG+ppI28uIVO8EItiPB4/ZhEjyPfNVHcqTvMG6wb4= =3Bm/ -----END PGP SIGNATURE-----
participants (3)
-
Jay Binks
-
Raul Fragoso
-
Łukasz Zwierko