[OpenSIPS-Users] SIP message relay order

[Stas Kobzar]

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_lifetime < 2) usleep("200000");

This actually works fine for me.

Thank you for your help and ideas!

On Tue, Feb 7, 2017 at 8:45 AM, Stas Kobzar <stas.kobzar at modulis.ca> wrote:

> 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 second might work fine here.
>
> Thank you for your help!
>
>
> On Tue, Feb 7, 2017 at 5:10 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> 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 Developerhttp://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 <
>> <bogdan at opensips.org>bogdan at opensips.org> 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
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://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 <%28514%29%20284-2020>
>>>
>>> Email: s <http://firstname.lastname>tas.kobzar at modulis.ca
>>>
>>> https://www.modulis.com
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> --
>>
>> Stas Kobzar
>>
>> Developeur VoIP / VoIP Developer
>>
>> Modulis­.ca Inc.
>>
>> # Bureau / Office: 514-284-2020 x 246 <(514)%20284-2020>
>>
>> Email: s <http://firstname.lastname>tas.kobzar at modulis.ca
>>
>> https://www.modulis.com
>>
>>
>
>
> --
>
> Stas Kobzar
>
> Developeur VoIP / VoIP Developer
>
>
> Modulis­.ca Inc.
>
> # Bureau / Office: 514-284-2020 x 246 <(514)%20284-2020>
>
> Email: s <http://firstname.lastname>tas.kobzar at modulis.ca
>
> https://www.modulis.com
>



-- 

Stas Kobzar

Developeur VoIP / VoIP Developer


Modulis­.ca Inc.

# Bureau / Office: 514-284-2020 x 246

Email: s <http://firstname.lastname>tas.kobzar at modulis.ca

https://www.modulis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170209/72347a0e/attachment-0001.html>