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:[EMAIL PROTECTED]
> Inviato: ven 25/07/2008 12.35
> A: Zappasodi Daniele
> Cc: users@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.
>
> **********************************************************************
_______________________________________________
Users mailing list
Users@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
