Hi, I believe we need more details on how to handle UPDATE compared to Re-INVITE or PRACK/100rel. The major differentiator is that an UPDATE can happen prior to the session being accepted, e.g. you could change your codec after sending the initial INVITE and before the B-Party accepts the call. I always wanted to check if I could implement a local "UPDATE" Generation in the b2b-modules, as it would allow us to handle preconditioning (as in VoLTE) locally. However, I haven't had the time to dig deeper into this yet. I've also seen UPDATE used to verify a session-keep-alive, which (likely) should only be answered and not further processed.
Probably, we can do something more clever than Oracle ;-) Just thinking out loud, Carsten -- Schöne Grüße aus Hamburg, dem Tor zur Welt, Carsten Bock Baron-Voght-Str. 128a I 22607 Hamburg I Germany T +49 179 2021244 I [email protected] LinkedIn: https://www.linkedin.com/in/carstenbock/ Am Mi., 26. Nov. 2025 um 09:37 Uhr schrieb Johan De Clercq <[email protected] >: > Update support would also be handy. For ease of use there should be update > to reinvite (update is a massive problem). > as you like the oracle documents, here is a link > https://docs.oracle.com/cd/E95618_01/html/sbc_scz810_acliconfiguration/GUID-17824ABA-36FE-4E50-A6EB-F3BADEA9767E.htm > . > > I implement this feature everywhere. > > -Johan. > > Verzonden vanuit Outlook voor iOS <https://aka.ms/o0ukef> > ------------------------------ > *Van:* Users <[email protected]> namens Bogdan-Andrei > Iancu <[email protected]> > *Verzonden:* Wednesday, November 26, 2025 8:59:10 AM > *Aan:* OpenSIPS users mailling list <[email protected]>; Vlad Paiu > <[email protected]> > *Onderwerp:* Re: [OpenSIPS-Users] PRACK interworking requirements > > Hey Vlad, > > Yeah, the function is a good starting point, but maybe for internal usage, > either with a wrapper on top or in an auto mode, in order to take care of > all 100rel specifics. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > On 25.11.2025 18:23, Vlad Paiu wrote: > > note that we currently have > https://opensips.org/html/docs/modules/3.6.x/dialog.html#func_dlg_send_sequential > , it can be used to generate a PRACK ( you'll have to manually add the Rseq > header), but it's not working properly if the upstream has multiple TO-TAGS > that are ringing ( it will always generate to the newest learnt to-tag, and > there's also some quirks with CSEQ mapping ), so perhaps the 'manual' > approach would be getting dlg_send_sequential to work properly for > generating early requests ( with PRACK being a rather specific use-case due > to it's cseq/rseq stuff ) > On 11/25/25 13:14, Giovanni Maruzzelli wrote: > > > On Tue, Nov 25, 2025, 11:57 Bogdan-Andrei Iancu <[email protected]> > wrote: > > > The result here should be a dlg dedicated function to generate a PRACK > from the onreply_route, like "dlg_answer_with_prack()" kind of function? or > should we look into a more automatic approach, like flagging the dialog at > creation to automatically generate the PRACK upon replies flagged with so? > > > personally I'm a control freak and would like better an explicit function, > maybe even with parameters to modify things if needed :)) > > -giovanni > > > > > > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > On 25.11.2025 11:46, Giovanni Maruzzelli wrote: > > hello OpenSIPSers, > > in previous mails has been noticed that various ITSPs are starting to > require PRACK support. > > We know that PRACK belongs to endpoints, specifically phones and B2BUAs. > > But... > > There can be a use case where OpenSIPS will work as SBC (not necessarily > using the b2b module) > > So, we can have a case where we would like to support that the dialogue > module insert the 100rel in the Supported: INVITE's header, and manage to > send a PRACK method to acknowledge provisional responses > > If and when 100rel/PRACK are "generated" by OpenSIPS, they will be > filtered out (not propagated) to/from the endpoints, even if the endpoint > would like to support it > > Reference RFC: https://www.ietf.org/rfc/rfc3262.txt > > I believe this will be enough to make ITSPs happy. > > Further developments can be moved to future. > > Would be very very nice to have this feature backported to OpenSIPS 3.6, > being it the last of the 3.X series, and an LTS > > Please let's gather here your thoughts , requests, corrections and > observations on this issue. > > Have a nice Monday you all! > > -giovanni > > -- > Sincerely, > > Giovanni Maruzzelli > OpenTelecom.IT > cell: +39 347 266 56 18 > > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing > [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 >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
