Hi Binan, Thanks for the follow up!
On Mon, Aug 20, 2012 at 1:37 PM, Binan AL Halabi <[email protected]> wrote: > > hi again, > check this : http://lists.opensips.org/pipermail/users/2010-March/011622.html > it could be useful. In fact it helped me, get some more understanding for the process, but I still can't find the problem... I added a failure_route for external requests: failure_route[external_fault] { xlog("L_INFO", "$ci|pass|JJJ: Failure Route"); if (t_check_status("302")) { xlog("L_INFO", "$ci|pass|JJJ: 302 in Failure Route"); xlog("L_INFO", "$ci|pass|JJJ: RURI: $ru"); if(get_redirects("*")) { xlog("L_INFO", "$ci|pass|JJJ: 302 in Failure Route: got redirects"); } xlog("L_INFO", "$ci|pass|JJJ: RURI: -> $ru"); if (!serialize_branches(1)) { xlog("L_INFO", "$ci|pass|JJJ: 302 in Failure Route: serialize_branches failed"); } if(!next_branches()) { xlog("L_INFO", "$ci|pass|JJJ: 302 in Failure Route: next_branches failed"); } t_relay(); xlog("L_INFO", "$ci|pass|JJJ: 302 in Failure Route after relay"); exit; } } But now, opensips blackoholes the 302 response and doesn't send it out again: Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|start|received udp request INVITE sip:[email protected]:7767;line=jxlhtxze Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|source 13.13.13.66:5060 Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|from sip:[email protected] Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|to sip:[email protected]:7767;line=jxlhtxze Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|originated from internal sources Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|added this server to the route set Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|pass|17.17.17.245:7767 Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|start|received external reply 302 Moved Temporarily Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|source 17.17.17.245:7767 Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|address in Via differs from source IP Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|13.13.13.66:5060 Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: Failure Route Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: 302 in Failure Route Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: RURI: sip:[email protected]:7767;line=jxlhtxze Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: 302 in Failure Route: got redirects Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: RURI: -> sip:[email protected]:7767;user=phone Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: 302 in Failure Route: next_branches failed Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|JJJ: 302 in Failure Route after relay Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|start|received external reply 404 Not Found Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|source 17.17.17.245:7767 Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|log|address in Via differs from source IP Aug 20 20:26:14 opensips opensips[24842]: 1d017902-6597-1230-2c88-0016367615cd|pass|13.13.13.66:5060 Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|start|received udp request ACK sip:[email protected]:7767;line=jxlhtxze Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|source 13.13.13.66:5060 Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|from sip:[email protected] Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|to sip:[email protected]:7767;line=jxlhtxze Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|originated from internal sources Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|log|added this server to the route set Aug 20 20:26:14 opensips opensips[24845]: 1d017902-6597-1230-2c88-0016367615cd|pass|17.17.17.245:7767 ------------------------------------------------------------------------- U 17.17.17.245:7767 -> 222.222.222.222:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 222.222.222.222;branch=z9hG4bK21aa.b4644ae.0. Via: SIP/2.0/UDP 13.13.13.66;received=13.13.13.66;rport=5060;branch=z9hG4bK61e7pDHD76Z9p. Record-Route: <sip:222.222.222.222;lr;ftag=KZaa3HU990pgN;did=177.49f25443>. From: "User B" <sip:[email protected]>;tag=KZaa3HU990pgN. To: <sip:[email protected]:7767;line=jxlhtxze>;tag=4f8mv5vtcq. Call-ID: 1d017902-6597-1230-2c88-0016367615cd. CSeq: 32407468 INVITE. Contact: <sip:[email protected];user=phone>. Diversion: <sip:[email protected]:7767;line=jxlhtxze>;reason="unconditional". Content-Length: 0. ------------------------------------------------------------------------- AND I still don't understand, why I even have to bother with these 302s myself.... I assumed, OpenSIPs would just forward the 302 from the user's phone to the PBX, *without* modifying it. I don't see in the script any function, that modifies the 302 response and replaces the contact URI like this: (as it happens without the failure_route handling) ------------------------------------------------------ U 17.17.17.245:7767 -> 222.222.222.222:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 222.222.222.222;branch=z9hG4bK2d04.95fa8d43.1. Via: SIP/2.0/UDP 13.13.13.66;received=13.13.13.66;rport=5060;branch=z9hG4bKU5NNyyH6X9e6D. Record-Route: <sip:222.222.222.222;lr;ftag=56rg7c7t2X5tD;did=295.f530e947>. From: "User B" <sip:[email protected]>;tag=56rg7c7t2X5tD. To: <sip:[email protected]:7767;line=jxlhtxze>;tag=ufd059ce98. Call-ID: 25960061-6590-1230-2c88-0016367615cd. CSeq: 32405972 INVITE. Contact: <sip:[email protected];user=phone>. Diversion: <sip:[email protected]:7767;line=jxlhtxze>;reason="unconditional". Content-Length: 0. . U 222.222.222.222:5060 -> 13.13.13.66:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 13.13.13.66;received=13.13.13.66;rport=5060;branch=z9hG4bKU5NNyyH6X9e6D. Record-Route: <sip:222.222.222.222;lr;ftag=56rg7c7t2X5tD;did=295.f530e947>. From: "User B" <sip:[email protected]>;tag=56rg7c7t2X5tD. To: <sip:[email protected]:7767;line=jxlhtxze>;tag=ufd059ce98. Call-ID: 25960061-6590-1230-2c88-0016367615cd. CSeq: 32405972 INVITE. Contact: <sip:[email protected]:7767;user=phone>. Diversion: <sip:[email protected]:7767;line=jxlhtxze>;reason="unconditional". Content-Length: 0. ------------------------------------------------------ So, it *does* forward the response to the PBX, but it modifies the contact-line from Contact: <sip:[email protected];user=phone>. to Contact: <sip:[email protected]:7767;user=phone>. and as a result, the PBX sends the new invite back to the diverting phone, which replies 404 not found -> no diversion, but a failed call. Why is OpenSIPS modifying this line at all, and how can I tell it, not to do that? ;-) Like I said, OpenSIPs should just load balance Calls/Registers and every single other message to the FreeSWITCH cluster. THANKS again for any help at all! ;-) Best Regards from a frustrated Johannes _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
