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