search

JNec / sipservlets

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

mobicents does not handle doAck properly when security is enabled #247

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Create a sip servlet with security constraints
2. A client sends an INVITE to the servlet
3. The server answers with a 401 Unauthorized
4. The client resend the INVITE with credentials
5. The servlet replies with a 200 OK
6. The client sends an ACK
7. Nothing happens. Mobicents does not execute the doAck method in the servlet.

What version of the product are you using? On what operating system?
mss-2.0.0.FINAL-jboss-as-7.1.2.Final

Please provide any additional information below.
I've attached a simple project that proves this bug.
ackbug.zip contains a simple sip servlet with security settings in sip.xml
If you remove security constraint from sip.xml the doAck method is executed.
acktest.zip is a sip unit test that acts as a client.
log_without_security is the log of the server when security is disabled.
log_with_security is the log of the server when security is enabled.

I tried to modify the server logic in order to force mobicents to enter the 
doAck. Particularly I've changed the SipSessionImpl#isAckReceived method (since 
the log says "isAckReceived for CSeq 2: null").
What I discovered was that the Sip Application Session of the ACK is different 
from the SAS of the INVITE when security is enabled.
When authorization is needed the client must send two INVITE. The first without 
the Authenticate header (followed by an ACK) and a second with the Authenticate 
header. It seems that the second ACK sent by the client has the same SAS of the 
first INVITE.

CLIENT ----INVITE----> SERVER (mobicents create a new SAS: SAS1)
CLIENT <-----401------ SERVER
CLIENT ------ACK-----> SERVER
CLIENT ----INVITE----> SERVER (mobicents create a new SAS: SAS2)
CLIENT <-----200------ SERVER
CLIENT ------ACK-----> SERVER (mobicents uses SAS1 to find if the ACK is 
already received)

You can see this in log_with_security_2 file.

Original issue reported on code.google.com by messa...@gmail.com on 4 Dec 2013 at 10:48

Attachments:

GoogleCodeExporter commented 8 years ago 
In the past few days I've investigated a little bit more and I found out that 
the issue come from SipUnit. In fact SipUnit add the tag in the To header of 
the second INVITE, which is wrong.

Anyway, based on the Sip Servlet 1.1 Spec, Appendix B, mobicents should answer 
with a 481 error:

"Existing Dialog Detection - If the request has a tag in the To header field, 
the container
computes the dialog identifier (as specified in section 12 of RFC 3261) 
corresponding to the
request and compares it with existing dialogs. If it matches an existing 
dialog, stop. The
request is not an initial request. The request is a subsequent request and must 
be routed to the
application path associated with the existing dialog. If the request has a tag 
in the To header
field, but the dialog identifier does not match any existing dialogs, the 
container must reject
the request with a 481 (Call/Transaction Does Not Exist)."

Am I wrong?

Original comment by messa...@gmail.com on 2 Jan 2014 at 9:15

GoogleCodeExporter commented 8 years ago 
See https://github.com/Mobicents/sip-servlets/issues/17

Original comment by jean.deruelle on 17 Dec 2014 at 9:37