Fallback to second DNS Record is not even attempted in event of TCP Connection failure

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Setup DNS Server (bind or dnsmasq) with 2 A records for host 
machine.yourdomain.com pointing to machines with IP address 10.10.10.10 and 
20.20.20.20.
2. Write a simple app to create and send a new Sip Message request to host 
sip:machine.yourdomain.com;transport=tcp as Route header.
3. Deploy and start the app. Capture the generated Sip requests and TCP 
messages using wireshark

What is the expected output? What do you see instead?

Mobicents should initiate Sip Transaction to one machine over TCP transport 
after DNS lookup. In case of no response or connection failure, invoke 
connection to second machine.

Observed that Mobicents falls back to second machine as expected only in case 
of no response; i.e. when there is already a TCP connection with target machine 
and that does not send back a response within transaction lifetime of 32 
seconds.
However when there is no TCP connection already in place with first machine and 
Mobicents tries to create one, observed that it directly throws back 
SocketException to application in event of TCP connection failure. It does not 
even attempts connection to the second machine.

What version of the product are you using? On what operating system?

mss-1.7.0.FINAL-apache-tomcat-6.0.35 on Redhat 6

Please provide any additional information below.

Section 4.3 of RFC 3263 mentions following procedure to process outgoing SIP 
request for which multiple SRV records are returned in DNS lookup:

   For SIP requests, failure occurs if the transaction layer reports a
   503 error response or a transport failure of some sort (generally,
   due to fatal ICMP errors in UDP or connection failures in TCP).
   Failure also occurs if the transaction layer times out without ever
   having received any response, provisional or final (i.e., timer B or
   timer F in RFC 3261 [1] fires).  If a failure occurs, the client
   SHOULD create a new request, which is identical to the previous, but
   has a different value of the Via branch ID than the previous (and
   therefore constitutes a new SIP transaction).  That request is sent
   to the next element in the list as specified by RFC 2782.

Original issue reported on code.google.com by girish...@gmail.com on 8 Jan 2014 at 10:54

[GoogleCodeExporter]

Can you attach the wireshard and logs of the server with category org.mobicents 
at DEBUG level ?

Original comment by jean.deruelle on 25 Apr 2014 at 7:23

• Changed state: Pending

[GoogleCodeExporter]

Also please try with latest SNAPSHOT from 
https://mobicents.ci.cloudbees.com/job/Mobicents-SipServlets-Release/lastSuccess
fulBuild/artifact/

Original comment by jean.deruelle on 25 Apr 2014 at 7:24

[GoogleCodeExporter]

Original comment by jean.deruelle on 5 May 2014 at 5:08

• Changed state: Started

[GoogleCodeExporter]

Original comment by jean.deruelle on 5 May 2014 at 5:08

• Added labels: TelScale-7.0.2.GA

[GoogleCodeExporter]

This issue was updated by revision 1d50592797c0.

fix + non regression test

(cherry picked from commit 4295437a866dc77d7c3bd21fa9e76b24be75f1fd)

Original comment by jean.der...@telestax.com on 6 May 2014 at 2:46

[GoogleCodeExporter]

Original comment by jean.deruelle on 6 May 2014 at 2:47

• Changed state: Fixed

[GoogleCodeExporter]

Tested this fix on MSS 3.0.0 SNAPSHOT build 1405281653 and observed that TCP 
connection to all DNS records are attempted now. However, found that existing 
Error Handling related to TCP connection failure seems to have got broken by 
this fix as explained below.

When Sip Request is being sent out over TCP transport, the send operation can 
fail in following two ways:
1. There is no TCP Server listening on remote target and TCP SYN packet is not 
answered causing TCP connection attempt to fail. Earlier, SocketException was 
thrown by Container back to application on SipServletRequest.send() call in 
event of this TCP Connection failure. However, no exception is being thrown by 
container now and hence Application does not get any intimation whenever such a 
TCP Connection failure happens. Although, Container does attempt all TCP 
targets with TCP SYN packet now which was not done earlier.
2. TCP Connection to remote is successful (or there was already a active 
connection to TCP target) and Sip Request is delivered over the TCP connection 
to remote. In such a scenario, timer F is started by container. If no response 
is received for the delivered request before expiry of F timer i.e. 32 seconds, 
 application is notified with 408 Timeout Response. This functionality was also 
working fine with MSS 1.7.0, but not in MSS 3.0.0 and hence application is not 
getting notified at all about failure of outgoing Sip Request.

As explained above, application is not receiving any callback or exception from 
MSS container 3.0.0 in event of TCP connection failure. Has there been some 
change in this functionality or is this a new issue?

Original comment by girish...@gmail.com on 23 Jun 2014 at 9:36

[GoogleCodeExporter]

I'm reopening the issue to investigate those new issues

Original comment by jean.der...@telestax.com on 23 Jun 2014 at 1:00

• Changed state: Reopened

[GoogleCodeExporter]

Hi, any news on this issue. I'm encountering into same scenario (1) as 
described above.

Original comment by flavioba...@gmail.com on 14 Jul 2014 at 3:49

[GoogleCodeExporter]

Issue was moved to GitHub:

https://github.com/Mobicents/sip-servlets/issues/35

Original comment by desi.pep...@telestax.com on 18 Dec 2014 at 6:55

[GoogleCodeExporter]

Original comment by jean.deruelle on 18 Dec 2014 at 9:27

• Changed state: Moved

[GoogleCodeExporter]

Can you guys retry with the latest build from 
https://mobicents.ci.cloudbees.com/job/MobicentsSipServlets-Release/ to see if 
that works. Some recent fixes were made to that.

Original comment by jean.deruelle on 25 Jun 2015 at 4:10