Hi Binan, That's in theory and it will be wonderfull if all devices will follow that. But in real world, as Ryan pointed out, just a few UAC implementations do properly handle a 491 to a reINVITE.
Regards, Bogdan Sent from Samsung MobileBinan AL Halabi <[email protected]> wrote:Hi ALL, According to 14.1 and 14.2 of RFC 3261 after receiving 491 the UAC will retry again after 2.1-4.0 seconds if it owns the CALL-ID or 0.0.-2.0 if not. So If UAS have an ongoing in-dialog ping and receive another one let it send 491 and drop the request (the end point will retry it later). // Binan. Från: Bogdan-Andrei Iancu <[email protected]> Till: OpenSIPS users mailling list <[email protected]> Kopia: OpenSIPS devel mailling list <[email protected]> Skickat: torsdag, 1 november 2012 12:02 Ämne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release Hi Dan, Well, as Ovidiu said, it is prone. BUT, this is not something particular to re-INVITE, but to whatever in-dialog pinging you may have from a mid-proxy. On the other hand, as Ryan pointed out here, the need to check the dialog health from proxy side, without relying on special end-UA features (like SST), is really critical. So, I see two approaches: 1) either simply live with the fact that races may occure and calls may be dropped during a re-INVITE, but at least is a clear drop /cut 2) theoretically we can try to address the race at dialog modules level : (a) If you have ongoing in-dialog transaction, do not do your ping , (b) if you have an ongoing in-dialog ping and receive another in-dilog request from end point, try to delay it until your pinging is done.....just some ideas.... Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/31/2012 09:03 PM, Dan Pascu wrote: > On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote: > >> Hi Saul, >> >> We were thinking at re-INVITE pinging from OpenSIPs level towards the caller >> and callee. There will be 2 modes (at least this is the current plan). >> 1) remember all the time the last SDPs from each side and re-use them >>when pining the other sides (just to trick the SDP negotiation) >> 2) start with a lateSDP negotiation on one side and do normal SDP on the >>other side (to avoid SDP storing), but this means at least one of the parties >>should support late SDP negotiations >> 3) open to other suggestions.... > I think this invites trouble as it is prone to race conditions. If any of the > clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it > will fail as there is already an active unanswered re-INVITE in progress. The > client will be confused as it didn't send another re-INVITE itself and the > negative reply to its own re-INVITE will probably just prompt the client to > terminate the session thinking there is some issue with it. > > I cannot see this working without a full B2BUA, where OpenSIPs would queue > the client requests if there is a ping in progress and only forward them > after it has finished the ping transaction. > >> About the GRUU stuff, could you detail a bit :D ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> >> On 10/26/2012 06:51 PM, Saúl Ibarra Corretgé wrote: >>> Hi, >>> >>> On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote: >>> >>>> Hi all, >>>> >>>> I would like to start a discussion about the next OpenSIPS major release - >>>> and in this discussion anyone is welcomed with options, ideas, critics and >>>> other. Your feedback is important to drive the project into a direction >>>> that reflects the user's needs!. >>>> >>>> So, I will here the starting points, for both release planing and release >>>> content. >>>> >>>> >>>> Content >>>> ------- >>>> What was done: >>>> http://www.opensips.org/Main/Ver190#toc2 >>>> What is planned: >>>> http://www.opensips.org/Main/Ver190#toc9 >>>> Planned items have priorities (for being addressed); it is a must to have >>>> all items done for the next release, as we need to fit into a time frame. >>>> Whatever is not done, will be left for the next release (1.10) >>>> >>>> >>>> Planing >>>> ------- >>>> Release candidate: >>>> second half of January 2012, depending on the progress with the items >>>>to be done. >>>> Testing phase: >>>> 1 month allocated (it may be extended if critical problems show up) >>>> Stable release: >>>> second half of February (after the testing phase is done). >>>> >>>> >>>> Once again, your feedback on these matters is important to us. >>>> >>> I'll edit the wiki with the items we've been working on for presence. >>> >>> Can you give a bit more detail on the dialog ping with re-INVITEs? >>> re-INVITEs are particularly troublesome, because there can only be one of >>> them at a time. >>> >>> Also, can we add the in-dialog requests when using GRUU bug to the >>> wishlist? :-) >>> >>> Keep up the good work guys! >>> >>> >>> Regards, >>> >>> -- >>> Saúl Ibarra Corretgé >>> AG Projects >>> >>> >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
