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.
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).
This is the trace (debug level 3, Openser version 1.3.2):
Jun 25 16:30:01 SAM-IP ser[23888]: R1 t_relay R-uri: sip:10240@10.45.10.63:2054;transport=tcp;line=zdhv6xi4 Jun 25 16:30:01 SAM-IP ser[23888]: Branch route sip:10240@10.45.10.63:2054;transport=tcp;line=zdhv6xi4 1 Jun 25 16:30:01 SAM-IP ser[23888]: Branch route sip:10240@10.45.10.36:5064;transport=tcp 2
Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (113) No route to host Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcp_send: connect failed Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:tm:msg_send: tcp_send failed Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:tm:t_forward_nonack: sending request failed
Jun 25 16:30:04 SAM-IP ser[23890]: Reply Route: provision 180 - Ringing ip <10.45.10.36:33109> From sip:10242@10.45.8.249 To sip:10240@10.45.8.249 Jun 25 16:30:04 SAM-IP ser[23890]: ERROR:core:io_wait_loop_sigio_rt: ignoring event 41 on fd 24 (fm->fd=-1, fm->data=0x406e5488) Jun 25 16:30:04 SAM-IP ser[23900]: ERROR:core:io_wait_loop_sigio_rt: ignoring event 41 on fd 25 (fm->fd=-1, fm->data=0x406c5258) Jun 25 16:30:11 SAM-IP ser[23889]: Reply Route: 487 - <Request Terminated> ip <10.45.10.36:33110> From sip:10242@10.45.8.249 To sip:10240@10.45.8.249 Jun 25 16:30:11 SAM-IP ser[23890]: ERROR:core:io_wait_loop_sigio_rt: ignoring event 41 on fd 24 (fm->fd=-1, fm->data=0x406d5370) Jun 25 16:30:11 SAM-IP ser[23891]: ERROR:core:tcp_read: error reading: Connection reset by peer Jun 25 16:30:11 SAM-IP ser[23891]: ERROR:core:tcp_read_req: failed to read
********************************************************************** 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.
**********************************************************************
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
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@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.
**********************************************************************
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@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.
-
Klaus Darilion -
Zappasodi Daniele