RE: [Users] Dealing with reinvites

I see what you mean, and was worried that would be the answer .. :-) against the first transaction it created. Since the cseq's are different, Asterisk flips out, since it expects the 102 cseq before the 103 .. This is normal behavior, right? invite didn't arrive or create a temporary transaction and wait for both ACKs. Well, the cats out of the bag, this carrier doesn't want to disable reinvites.. I think they have altered the Asterisk code to send a reinvite ASAP as opposed to 'waiting' for the RTP stream to setup. We have never ever had this problem before.. For those of you wondering, the carrier is TXLink.. Any other suggestions? Hehe. Thanks much. Matt -----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro] Sent: Saturday, December 31, 2005 6:55 AM To: Matt Schulte Cc: users(a)openser.org Subject: Re: [Users] Dealing with reinvites Hello, without the full grep of the packages, I am doing just assumptions. The ACK is for first INVITE, so the the Asterisk should match it against the first transaction it created. For the second INVITE, it should wait for another ACK. This is a common race in IP world due to different path routing and cannot be avoided, even if you fix something on openser, the delay may occur on the wire. The ACK sent for a 200OK is a separate transaction, and it is routed according to Route headers. You cannot change it in OpenSER/SER unless you make the proxy to be call stateful, to act as an end User Agent. I am not sure what the RFC says exactly about how the end User Agent must act. It may be logically to drop the re-INVITE if the ACK for the first invite didn't arrive or create a temporary transaction and wait for both ACKs. Cheers, Daniel On 12/30/05 17:09, Matt Schulte wrote: connect to it on my end. problems.