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
Alexandre Abreu wrote:
Hello.
Below it's the call flow.
UAC CALL CONTROL 1 OPENSER 1 GW
| | | |
| INVITE F1 | | |
|--------------->| | |
| 100 F2 | | |
|<---------------| INVITE F3 | |
| |--------------->| |
| | 100 F4 | |
| |<---------------| INVITE F5 |
| | |--------------->|
| | | 183 F6 |
| | 183 F7 |<---------------|
| 183 F8 |<---------------| |
|<---------------| | |
| | Early Media | |
|<==============>|<===============|================|
| | | 200 F9 |
| | 200 F10 |<---------------|
| |<---------------| |
| | | |
| | ACK F13 | |
| |--------------->| |
| | re-INVITE F14 | |
| |--------------->| |
| | | re-INVITE F15 |
| |
|--------------->| |
| | ACK F16 |
| | |--------------->|
| | | |
| | | 500 F17 |
| | | <--------------|
| | | |
The problem is between F13 and F16. Why OPENSER relays the re-INVITE
first
(F15), if the ACK (F13) was sent before and arrives before?
And I am sure that this ACK hits a t_relay(), because after the re-INVITE
sent, the ACK (F16) is sent normally...
I am using OpenSER 1.0.1.
Any help is appreciated.
Alexandre
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users