On Sun, 2009-11-22 at 23:06 +0100, Mikael Magnusson wrote:
> The trunk doesn't handle CANCEL requests correctly. CANCEL requests are
> now sent to the INVITE server transaction where they are dropped:
> INVITE: Server transaction: Received request is not particularly
> alike the first one ("45" CANCEL sip:t...@fowley.hem.za.org /= "45"
> INVITE sip:t...@fowley.hem.za.org). Dropping it on the floor.
Ooops. Sorry for not catching that, I currently have no lab environment
for SIP development and rely solely on unit tests and Dialyzer.
It seems my simplification in r1724 was too much. YXA lost the ability
to create server transactions for the CANCELs themselves. I fixed that
and also improved the unit test cases in transactionstatelist.
In the process, I also made a test case that went beyond what I think
are appropriate for unit tests, but otherwise a great step forward. It
was a great step towards simulating a lab environment - a complete
integration test of most of YXA (testing appserver in this case). I need
to think a bit more about what kind of integration tests to introduce
before doing so though.
A limitation for test cases today is that they can't insert stuff into
the Mnesia databases. Some unit tests do, but they do it inside a
transaction that is then aborted. For integration tests, this technique
can't be used since nested transactions are only supported inside a
The question for integration tests then is if it should be a requirement
to run them in a non-production node with a separate set of mnesia RAM
tables or similar.
I also begun adding support for versioned configuration sets. It is a
really cool idea I've had for a long time, which turned out to be dead
simple to implement. The plan is to let currently running processes
(except long lived ones, like the transport layer etc.) use a fixed
version of the server configuration until they terminate. Meaning that
configuration changes made will not affect currently running
transactions etc. Expect to see more of this soon!
Yxa-devel mailing list