[Users] Re: ACK is sent before the re-INVITE to OpenSER

[Gene Willingham]

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 at 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 at voice-system.ro>
Cc: users at openser.org
Message-ID: <4461AA5C.7090403 at 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>>