Hi Stas,
If the ACK git the loose_route() / match_dialog(), then the state will
move to 4.
You may also use the $DLG_lifetime when handling the re-INVITE - if it
is less than 5 seconds, drop the re-INVITE :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02/06/2017 09:46 PM, Stas Kobzar wrote:
Hello Bogdan,
In my case, ACK for previous INVITE has already been received by
OpenSIPS, but not sent yet.
In this case, will the variable $DLG_status still equals 3 ?
Thanks
On Sun, Feb 5, 2017 at 11:15 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Stas,
Such races may happen at application level or even at network
level (when using UDP) - so if you have 2 packets very close as
time, they may swap. That is SIP :)
The full guilt is in the UAC device, IMHO - it should let some
time gap between the ACK and re-INVITE, to eliminate any possible
races.
Now, what you can do is to use the dialog module and to check the
dialog state when receiving the re-invite. If $DLG_status is /3/
(Confirmed by a final reply but no ACK received yet), drop with no
reply the re-INVITEs (to force a later retransmission) :
http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#id297400
<http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#id297400>
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com>
On 02/02/2017 10:31 PM, Stas Kobzar wrote:
Hello List,
My call flow has initial INVITE and re-INVITE to update RTP IP/port.
Usually everything works well, but sometimes OpenSIPS come up
with following example:
UA OpenSIPS PSTN GW
-------------------------------------------
INV(CSeq: 100) -----> | ---> INV(CSeq: 100)
<---- 200 OK | <--- 200 OK
(UA sends ACK then new INVITE)
ACK(CSeq: 100) -----> |
reINV(Cseq: 101) ---> |
(OpenSIPS relays first INVITE then ACK)
| ---> reINV(CSeq: 101)
| ---> ACK(CSeq: 100)
When PSTN gateway receives re-INVITE before ACK for previous INVITE
it responds 500 with Retry-After header.
This is correct behaviour which conforms to the RFC 3261 section 14.2
My question is:
Is it possible to assure order of received and relayed messages
within the same SIP session? Is there any configuration parameter?
Thank you,
--
Stas Kobzar
Developeur VoIP / VoIP Developer
Modulis.ca Inc.
# Bureau / Office: 514-284-2020 x 246 <tel:%28514%29%20284-2020>
Email: s <http://firstname.lastname>[email protected]
https://www.modulis.com <https://www.modulis.com/>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
--
Stas Kobzar
Developeur VoIP / VoIP Developer
Modulis.ca Inc.
# Bureau / Office: 514-284-2020 x 246
Email: s <http://firstname.lastname>[email protected]
https://www.modulis.com <https://www.modulis.com/>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
