After this SIP debugging, I can only assume FS cannot correctly process the maddr. The initial INVITE sent out results in a 302 from the redirect server with a contact of:

Contact:<sip:9995552000000@sip.blinkmind.net:5060;transport=udp;maddr=10.11.0.81>;q=0.5;ton=PUBLIC;ct=NIL;cat=OTHER

FS immediately sends out a New Invite back to the redirect server using the contact info of the 302 in the Req URI.

send 1145 bytes to udp/[10.11.0.20]:5060 at 03:04:36.240400:

------------------------------------------------------------------------

INVITE sip:9995552000000@sip.blinkmind.net SIP/2.0

Via: SIP/2.0/UDP 10.11.0.80:5080;rport;branch=z9hG4bKS42Dt0Qj0StQm

Max-Forwards: 68

From: "9995551000000" <sip:9995551000000@sip.blinkmind.net>;tag=S2XD2mKva2vHQ

To: <sip:9995552000000@sip.blinkmind.net>

Call-ID: 023221b8-244f-122e-3fa7-0018512d505c

CSeq: 671074 INVITE

Contact: <sip:gw+sip.blinkmind.net@10.11.0.80:5080;transport=udp;gw=sip.blinkmind.net>

User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY

Supported: timer, precondition, path, replaces

Allow-Events: talk, hold, refer

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 287

X-FS-Support: update_display

Remote-Party-ID: "9995551000000" <sip:9995551000000@sip.blinkmind.net>;party=calling;screen=yes;privacy=off

v=0

o=FreeSWITCH 1281981574 1281981575 IN IP4 10.11.0.80

s=FreeSWITCH

c=IN IP4 10.11.0.80

t=0 0

m=audio 32702 RTP/AVP 0 8 3 101 13

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:3 GSM/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:13 CN/8000

a=ptime:20

------------------------------------------------------------------------

recv 449 bytes from udp/[10.11.0.20]:32774 at 03:04:36.243214:

------------------------------------------------------------------------

SIP/2.0 302 Moved temporarily

Via:SIP/2.0/UDP 10.11.0.80:5080;branch=z9hG4bKS42Dt0Qj0StQm;rport

From:"9995551000000"<sip:9995551000000@sip.blinkmind.net>;tag=S2XD2mKva2vHQ

To:<sip:9995552000000@sip.blinkmind.net>;tag=1852618065-1282014276242

Call-ID:023221b8-244f-122e-3fa7-0018512d505c

CSeq:671074 INVITE

Contact:<sip:9995552000000@sip.blinkmind.net:5060;transport=udp;maddr=10.11.0.81>;q=0.5;ton=PUBLIC;ct=NIL;cat=OTHER

Content-Length:0

------------------------------------------------------------------------

send 372 bytes to udp/[10.11.0.20]:5060 at 03:04:36.243414:

------------------------------------------------------------------------

ACK sip:9995552000000@sip.blinkmind.net SIP/2.0

Via: SIP/2.0/UDP 10.11.0.80:5080;rport;branch=z9hG4bKS42Dt0Qj0StQm

Max-Forwards: 68

From: "9995551000000" <sip:9995551000000@sip.blinkmind.net>;tag=S2XD2mKva2vHQ

To: <sip:9995552000000@sip.blinkmind.net>;tag=1852618065-1282014276242

Call-ID: 023221b8-244f-122e-3fa7-0018512d505c

CSeq: 671074 ACK

Content-Length: 0

------------------------------------------------------------------------

send 1184 bytes to udp/[10.11.0.20]:5060 at 03:04:36.243999:

------------------------------------------------------------------------

INVITE sip:9995552000000@sip.blinkmind.net:5060;transport=udp;maddr=10.11.0.81 SIP/2.0

Via: SIP/2.0/UDP 10.11.0.80:5080;rport;branch=z9hG4bKtDv6UU8NX2gag

Max-Forwards: 68

From: "9995551000000" <sip:9995551000000@sip.blinkmind.net>;tag=tBQ63F4Z7aK4j

To: <sip:9995552000000@sip.blinkmind.net>

Call-ID: 0232b20c-244f-122e-3fa7-0018512d505c

CSeq: 671074 INVITE

Contact: <sip:gw+sip.blinkmind.net@10.11.0.80:5080;transport=udp;gw=sip.blinkmind.net>

User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY

Supported: timer, precondition, path, replaces

Allow-Events: talk, hold, refer

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 290

X-FS-Support: update_display

Remote-Party-ID: "9995551000000" <sip:9995551000000@sip.blinkmind.net>;party=calling;screen=yes;privacy=off

v=0

o=FreeSWITCH 1281981574 1281981576 IN IP4 10.11.0.80

s=FreeSWITCH

c=IN IP4 10.11.0.80

t=0 0

m=audio 32702 RTP/AVP 0 8 3 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:3 GSM/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=ptime:20

------------------------------------------------------------------------

recv 448 bytes from udp/[10.11.0.20]:32774 at 03:04:36.246197:

------------------------------------------------------------------------

SIP/2.0 302 Moved temporarily

Via:SIP/2.0/UDP 10.11.0.80:5080;branch=z9hG4bKtDv6UU8NX2gag;rport

From:"9995551000000"<sip:9995551000000@sip.blinkmind.net>;tag=tBQ63F4Z7aK4j

To:<sip:9995552000000@sip.blinkmind.net>;tag=343356216-1282014276245

Call-ID:0232b20c-244f-122e-3fa7-0018512d505c

CSeq:671074 INVITE

Contact:<sip:9995552000000@sip.blinkmind.net:5060;transport=udp;maddr=10.11.0.81>;q=0.5;ton=PUBLIC;ct=NIL;cat=OTHER

Content-Length:0

------------------------------------------------------------------------

send 407 bytes to udp/[10.11.0.20]:5060 at 03:04:36.246339:

------------------------------------------------------------------------

ACK sip:9995552000000@sip.blinkmind.net:5060;transport=udp;maddr=10.11.0.81 SIP/2.0

Via: SIP/2.0/UDP 10.11.0.80:5080;rport;branch=z9hG4bKtDv6UU8NX2gag

Max-Forwards: 68

From: "9995551000000" <sip:9995551000000@sip.blinkmind.net>;tag=tBQ63F4Z7aK4j

To: <sip:9995552000000@sip.blinkmind.net>;tag=343356216-1282014276245

Call-ID: 0232b20c-244f-122e-3fa7-0018512d505c

CSeq: 671074 ACK

Content-Length: 0

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steven Ayre
Sent: Wednesday, August 11, 2010 4:39 PM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] FS processing 302

AFAIK 302 reenters the dialplan. If the destination number is unchanged, it will execute the same commands after the redirect as it did before the redirect, which would likely cause it to continously bridge, redirect, bridge, redirect.... That could explain what you're experiencing.

How do you want to handle the 302?

It's advisable to be careful what to do with a 302 which is why it reenters the dialplan. You can try dialing a $0.01 route but have it redirect you to a $1.00 route leaving you sending the call out on a route costing you $1.00 but charging your customer $0.01, or if you do bill them correctly leaving them with a bill of $1.00 when they expected only $0.01.

It's possible to handle a 302 manually by sending them to a dialplan context specifically for it, which keeps the redirect logic away from your main dialplan. See http://wiki.freeswitch.org/wiki/Dialplan_Handling_Incoming_Redirect

-Steve