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@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@voice-system.ro Cc: users@openser.org Message-ID: 4461AA5C.7090403@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>>
Gene,
If you want that all sequential request (within the dialog, as ACK, BYE, re-INVITEs) to pass through your proxy, you need to do record_route and loose_route. The within the dialog requests will be routed based on the Route header.
regards, bogdan
Gene Willingham wrote:
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@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@voice-system.ro Cc: users@openser.org Message-ID: 4461AA5C.7090403@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>>
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Gene Willingham