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@foo.bar', not `ACK xyz@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@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