Hello,
Finally, I came up with something that works as I want it.
I have tried to drop re-INVITE when DLG_lifetime is < 1sec. I worked. But,
as the re-INVITEs were the part of direct media negotiation, I had some
"cuts" in the audio in very beginning of the call.
So, I do following:
if ($DLG_lif
Hi Bogdan,
It seems like $DLG_status will not work in my case.
But $DLG_lifetime probably can work. 5 seconds might be too long in my
case, though.
I have re-INVITE almost immediately after initial INVITE (it is Asterisk,
trying to renegotiate SDP media IP/port for direct media).
I guess 1 secon
Hi,
I also was thinking about usleep as in Nick's solution.
My OpenSIPS version is 1.11 and async, AFAIK, is available starting with
version 2.1, isn't it?
Thanks,
On Tue, Feb 7, 2017 at 7:35 AM, Bogdan-Andrei Iancu
wrote:
> Hi Nick,
>
> It is risky to do a sync sleep as you keep the process
Hi Nick,
It is risky to do a sync sleep as you keep the process blocked, so the
ability of OpenSIPS to handle new messages will decrease .
Either do async sleep, either simple drop it to force a retransmissions
in 500ms - much simpler :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and De
The easies way we use in such cases is:
if (is_method("INVITE")) usleep("500");
for in-dialog INVITEs (inside loose_route() / match_dialog() section).
It will delay slightly all reINVITES, but also will guarantee correct order
of packets.
2017-02-06 22:46 GMT+03:00 Stas Kobzar :
> Hello Bogdan,
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-so
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
wrote:
> Hi Stas,
>
> Such races may happen at application level o
Hello Bogdan and Razvan,
Thank you for sharing your ideas.
Dropping re-INVITE packet to force retransmission sounds really smart
solution for that issue! Also it is easy to implement.
I will give it a try.
Thanks again!
On Sun, Feb 5, 2017 at 11:15 AM, Bogdan-Andrei Iancu
wrote:
> Hi Stas,
>
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 p
Hi, Stas!
I can't think of any way to overcome this. However, re-INVITEs and ACK
should be treated in the same manner, without too much processing.
My assumption is that you are doing some extra processing on re-INVITEs
which might delay its forward. Can you check that?
Best regards,
Răzvan
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: 10
11 matches
Mail list logo
