On Tue, 2009-08-25 at 21:47 +0200, Mikael Magnusson wrote:
> On Fri, 2009-06-26 at 21:58 +0200, Mikael Magnusson wrote:
> > Hi,
> > 
> > there is a problem with the transaction matching code. If Yxa receives
> > an INVITE request over TCP and CANCEL over UDP, then Yxa is not able to
> > find the INVITE transaction and instead forwards the CANCEL in a new
> > transaction. This new transaction in turn receives a 481 response, since
> > it didn't match the INVITE Yxa sent earlier.
> > 
> > I think the problem is in the sipheader:via_sentby/1, which should
> > ignore the transport protocol since there is no guaranteed that the
> > INVITE and CANCEL are received over the same transport protocol. The
> > sender might have switched to TCP for the INVITE because of its size,
> > and defaults to UDP for CANCEL.

I _finally_ got the time to finish this (r1728, and then merged to trunk
in r1729).

As usual, I made a much bigger deal of things in my quest to have proper
regression testing for each and every bug I fix. I ended up moving a
bunch of functions from sipheader.erl to transactionstatelist.erl and
then implementing the first set of unit tests for the transaction
matching code. Good thing - too bad it took so long :(.


Yxa-devel mailing list

Reply via email to