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.kob...@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 <bog...@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 < >> <bog...@opensips.org>bog...@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.kob...@modulis.ca >>> >>> https://www.modulis.com >>> >>> _______________________________________________ >>> Users mailing >>> listUsers@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.kob...@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.kob...@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.kob...@modulis.ca https://www.modulis.com
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users