Hi Jiri, David, Thank you very much for your timely replies. I will check if the ACK hits t_relay or not in my configuration. I have skimmed through the transaction matching code in SER but I don't remember if it checks the FROM field or the FROM tag. I'll verify this when I can. Minh _____ De : Wearne, David W. [mailto:DWWearne@west.com] Envoyé : jeudi 6 janvier 2005 20:56 À : PHAN, Quang-Minh (Docteur Ordinateur); serusers(a)lists.iptel.org Objet : RE: [Serusers] Problem with ACK on Negative Reply I ran into exactly the same problem in December. There are several reasons why SER may not realize the ACK belongs to the transaction. Look carefully at the via: and from: headers in the INVITE and the ACK. The via: should have a branch parameter, and it should be the same in both. Some UAs do not put in the branch parameter. In this case SER should (according to RFC3261) be looking at the combination of the Request URI, To tag, From tag, Call-ID, Cseq, and top via header. In my case the problem was that SER compares the this issue both here and in the serdev list, (you can find the thread in the December archives), but the developers said they would not fix this because it is in support of an obsolete spec (RFC 2543). I recommend you check those headers to see if your situation actually matches what I ran into, and if so, raise the issue to the serdev list. If enough people complain, they might decide to provide better support of RFC3261, section 17.2.3 (Matching Requests to Server Transactions). Dave _____ From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of PHAN, Quang-Minh (Docteur Ordinateur) Sent: Thursday, January 06, 2005 12:10 PM To: serusers(a)lists.iptel.org Subject: [Serusers] Problem with ACK on Negative Reply Hi all, When I use SER in transaction stateful mode, I have the following problem: When A sends an "INVITE B" to SER, SER forwards the INVITE to B statefully. If B reply with "200 OK", everything goes fine as SER will delete the transaction from memory when it sees the 200 OK. However, if B send an "BUSY HERE" back to SER, SER will send an ACK to B right away and then forwards the "BUSY HERE" to A. A will then send an ACK to SER but SER won't realize that the ACK belong to the transaction and forward it to B. SER will then keep sending "BUSY HERE" to A until the transaction is timed out. I wonder if there is something to add in the configuration file to make SER understand that the ACK send from A should terminate the transaction. Any help will be highly appreciated! Minh