25 Jul
2008
25 Jul
'08
5:35 p.m.
I think 503 would be better suited:
RFC 3261:
8.1.3.1 Transaction Layer Errors
In some cases, the response returned by the transaction layer will
not be a SIP message, but rather a transaction layer error. When a
timeout error is received from the transaction layer, it MUST be
treated as if a 408 (Request Timeout) status code has been received.
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.
regards
klaus
Zappasodi Daniele schrieb:
Hello,
I have investigated a bit.
The problem seems to be related to t_pick_branch.
In the case described it returns -2 because it found a branch still
unfinished (last_received<200) for the branch that has lost the TCP
connection.
I think that a first step could be assigning a value > 200 to
last_received for the branches that fail to send out the INVITE.
In t_forward_nonack
} else {
if (SEND_BUFFER(
&t->uac[i].request)==0) {
ser_error = 0;
break;
}
LM_ERR("sending request failed\n");
ser_error=E_SEND;
}
/* get next dns entry */
if ( t->uac[i].proxy==0 ||
get_next_su( t->uac[i].proxy,
&t->uac[i].request.dst.to,
(ser_error==E_IP_BLOCKED)?0:1)!=0 )
break;
I have added here something like this
if(ser_error==E_SEND)
t->uac[i].last_received=700;
// 700 ???
and now parallel forking works.
I don't know if it is enough, but what do yuo think about this small
change? could it be dangerous in other circumstances?
-----Messaggio originale-----
Da: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Inviato: ven 25/07/2008 12.35
A: Zappasodi Daniele
Cc: users(a)lists.openser.org
Oggetto: Re: [OpenSER-Users] Error with parallel forking and TCP
Zappasodi Daniele schrieb:
Hello,
I have a problem with parallel forking and TCP when one connection isn't
available and the inv_timeout expires.
I have two clients registered with the same username and transport=TCP.
If I make a call to this number when one of them is not reachable, the
INVITE goes to the phone reachable, if the call timeout expires
(fr_inv_timer_avp) Openser sends the CANCEL, but doesn't send anything
to the caller.
The failure_route doesn't hit.
Looks like a bug.
There is also a delay between the t_relay and the forwarding of the
packet TCP on the net (around 3 seconds). The TCP packet is forwarded to
the available connection only after Openser detects the failure for the
closed TCP connection (the INVITE goes on the net only after the message
ERROR:tm:t_forward_nonack: sending request failed).
I suspect the problem is synchronous blocking TCP operation. Openser
tries to send to first contact, then to second contact. As sending to
first contact fails (probably with a TCP timeout of 3 seconds - check
core book documentation for setting TCP timeouts) it takes 3 seconds
until it sends the request on the second connection.
regards
klaus
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************