[OpenSIPS-Users] opensips als LB for multi-FS cluster: nasty problems with TCP/TLS registered clients
Johannes Jakob
lists.jj at googlemail.com
Mon Aug 20 20:37:13 CEST 2012
Hi Binan,
Thanks for the follow up!
On Mon, Aug 20, 2012 at 1:37 PM, Binan AL Halabi
<binanalhalabi at yahoo.com> 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:1001 at 17.17.17.245: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:1002 at sip.isp.net
Aug 20 20:26:14 opensips opensips[24842]:
1d017902-6597-1230-2c88-0016367615cd|log|to
sip:1001 at 17.17.17.245: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:1001 at 17.17.17.245: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:1003 at 17.17.17.245: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:1001 at 17.17.17.245: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:1002 at sip.isp.net
Aug 20 20:26:14 opensips opensips[24845]:
1d017902-6597-1230-2c88-0016367615cd|log|to
sip:1001 at 17.17.17.245: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:1002 at sip.isp.net>;tag=KZaa3HU990pgN.
To: <sip:1001 at 17.17.17.245:7767;line=jxlhtxze>;tag=4f8mv5vtcq.
Call-ID: 1d017902-6597-1230-2c88-0016367615cd.
CSeq: 32407468 INVITE.
Contact: <sip:1003 at sip.isp.net;user=phone>.
Diversion: <sip:1001 at 17.17.17.245: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:1002 at sip.isp.net>;tag=56rg7c7t2X5tD.
To: <sip:1001 at 17.17.17.245:7767;line=jxlhtxze>;tag=ufd059ce98.
Call-ID: 25960061-6590-1230-2c88-0016367615cd.
CSeq: 32405972 INVITE.
Contact: <sip:1003 at sip.isp.net;user=phone>.
Diversion: <sip:1001 at 17.17.17.245: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:1002 at sip.isp.net>;tag=56rg7c7t2X5tD.
To: <sip:1001 at 17.17.17.245:7767;line=jxlhtxze>;tag=ufd059ce98.
Call-ID: 25960061-6590-1230-2c88-0016367615cd.
CSeq: 32405972 INVITE.
Contact: <sip:1003 at 17.17.17.245:7767;user=phone>.
Diversion: <sip:1001 at 17.17.17.245: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:1003 at sip.isp.net;user=phone>.
to
Contact: <sip:1003 at 17.17.17.245: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
More information about the Users
mailing list