Consider improving received ACK handling after 200 OK in UAS

[atsakiridis]

Scenario:

• Bob (UAC) sends INVITE to alice
• Alice (UAS) responds with 200 OK
• Bob sends ACK

Right now UAS works as improved in #79, which means that:

• When an ACK arrives, instead of using the last server transaction UAS is aware of (which proved very problematic in this scenario), it searches through all server transactions and matches based on RFC rules (described at RFC3261 section: 17.2.3 Matching Requests to Server Transactions) with the matching INVITE/200 OK transaction and uses that transaction + associated Dialog to do further handling

But instead of that as suggested by @jaimecasero we should create a new transaction (like createServerTransaction() here), and let the dialog layer control the ACK if the ACK is for 2xx, the dialog should be there in confirmed state, ready to handle ACK.

Notice that I tried to do that when working on #79, but seems that dialog ends up being null and the web app crashes, so it seems that it needs deeper investigation to see what is going on. Also notice that the proposed design is taken from JAIN SIP for Java and it might not fit in the design of JAIN SIP JS. So it needs examination.