search

noushadali / sipservlets

Automatically exported from code.google.com/p/sipservlets
0 stars 0 forks source link

Connection to only 2 SRV records in DNS Lookup are Attempted #249

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

1. Setup DNS Server (bind or dnsmasq) to return 4 SRV records for _sip._udp for 
yourdomain.com with same priority (10) and same weightage (25) and pointing to 
some ports on your local machine.
2. Write a simple app to create and send a new Sip Message request to 
username@yourdomain.com domain as Route header.
3. Deploy and start the app. Capture the generated Sip requests over UDP using 
wireshark

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

Mobicents should initiate Sip Transaction to first target over UDP transport. 
In case of no response (transaction timeout of 32 seconds), invoke connection 
to second target and so on.
However, observed that Mobicents tries only 2 of the target IP/Ports (based on 
Priority/Weightage) and not 3rd/4th targets.

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.

As mentioned here, no limit has been defined on SRV records to which Sip 
Request should be sent out.

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

GoogleCodeExporter commented 9 years ago 
Can you attach the wireshard and logs of the server with category org.mobicents 
at DEBUG level on 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:26

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision d65812392097.

Fix + non regression test

Original comment by jean.der...@telestax.com on 2 May 2014 at 9:55

GoogleCodeExporter commented 9 years ago

Original comment by jean.deruelle on 2 May 2014 at 9:56

GoogleCodeExporter commented 9 years ago 
Tested this fix on MSS 3.0.0 SNAPSHOT build 1405281653 and it is working 
perfectly fine. Configured 5 UDP targets for the same SRV record and all were 
attempted correctly one-after-another in order of priority and weight.

Thanks a lot!

Original comment by girish...@gmail.com on 23 Jun 2014 at 7:05

GoogleCodeExporter commented 9 years ago

Original comment by jean.der...@telestax.com on 23 Jun 2014 at 10:03

GoogleCodeExporter commented 9 years ago

Original comment by jean.der...@telestax.com on 25 Aug 2014 at 10:52