[Serusers] SER has problems matching ACKs to replies

[Jiri Kuthan]

At 04:56 PM 4/8/2003, Maxim Sobolev wrote:
>Sorry, further investigation shown that this particular problem was
>caused by the typo in our fix for hashing function (one found in 0.8.10
>didn't bother to strip insignificant chars from call-id and cseq number).
>I've fixed that and the problem gone.

fyi: The parser on CVS skips leading whitespaces.

>However, we have another problem with ACK matching. 
[...]

>Everything is fine when INVITE transaction ends with a 200 OK, in this
>case ATA generates ACK to acknowelege 200 OK using information from
>that 200 OK, i.e. `ACK 123456 at foo.bar', not `ACK xyz at foo.bar'. The problem
>happens if transaction ends with 4xx error, or is cancelled by the
>originating party, in this case ATA acknoweleges receipt of final negative
>response with `ACK xyz at foo.bar' so that tm module is unable to match ACK
>to original INVITE.
>
>Do you have any ideas how to properly solve this problem 

By asking Cisco to fix this bug -- I've been told that the ATA team is
very responsive (when talking to them, you can also ask to introduce
3261-compliant transaction matching). CVS version of SER has a configuration 
option which allows to disable r-URI matching for pre-3261 implementations 
with this bug. If you need to use a stable version, patching t_lookups.c
to skip uri matching should be fairly easy.

[...]

>I think that it should be possible to resolve the problem by modifying
>tm module to match ACKs for non-200 replies to original uri in INVITE
>instead to rewriten one. What do you think? Is there any potential
>problems with this approach?

I'm not aware of any noticable problems when r-uri is skipped. A potential
problem is consusing spirals with retransmissions but we already handle it
in another way -- outgoing requests include 3261-transaction-matching branch
which eliminates such ambiguities if the request is spiraled to the server
back again.

-Jiri