10 Apr
2003
10 Apr
'03
11:51 a.m.
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(a)foo.bar'#39;, not `ACK xyz(a)foo.bar'#39;. 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(a)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