I thought I was experiencing the same issue. But after looking at it
closely, I discovered the ACK is not being sent. I am not an expert with
OpenSER and may not be using the correct terminology, but I will try to
explain what I see happening.
I am using Openser as a gateway to our provider. We send invites from
asterisk to openser and we forward the invite to the provider. We are using
rewritehost followed by t_relay to route the requests. When we receive the
200 ok back from the provider we relay the message back to asterisk.
Asterisk responds with an ACK followed by the reinvites. The issue we are
seeing is the ack is not relayed at all, only the reinvites get relayed.
We then added the following to the top of openser.cfg:
# ---------------------------------------------
# Asterisk reinvite issue relay ACK immediately
# ---------------------------------------------
if (method=="ACK") {
forward(uri:host, uri:port);
route(1);
};
Now the ACK is being handled correctly. We are clearly missing something.
I suspect the same thing is happening on inbound calls with the relaying of
200 ok messages.
Gene
------------------------------
Message: 6
Date: Wed, 10 May 2006 10:54:52 +0200
From: Klaus Darilion <klaus.mailinglists(a)pernau.at>
Subject: Re: [Users] ACK is sent before the re-INVITE to OpenSER, but
the proxy relays the re-INVITE first (call flow in the body).
To: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
Cc: users(a)openser.org
Message-ID: <4461AA5C.7090403(a)pernau.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
IMO the receiving client should be tolerant and accept the reINVITe
although the ACK is missing/delayed, as the reINVITE is an implict ACK.
regards
klaus
Bogdan-Andrei Iancu wrote:
Hi Alexandre,
if I'm not wrong ,this topic was previously discussed on the mailing
list. The idea is that openser cannot guarantee that messages will be
sent in same order as received. And this because of parallel
multi-process execution.
the idea is that the CC1 shouldn;t send a re-INVITE so fast and also the
GW should wait a little bit to see if ACK is delayed or not.
if you are running in full debug, the logs will might help you to see
how the ACK and INVITE gets swapped during processing.
regards,
bogdan
<<snip>>