Have you had the chance to do any testing? It will help deciding to push the commit to branch 5.3 for the release of 5.3.4.
Cheers, Daniel On 05.05.20 09:55, Chris Martineau wrote: > > Thanks Daniel, > > > > Will test and advise. > > > > Chris > > > > *From:*sr-users <[email protected]> *On Behalf Of > *Daniel-Constantin Mierla > *Sent:* 04 May 2020 19:09 > *To:* Kamailio (SER) - Users Mailing List <[email protected]> > *Subject:* Re: [SR-Users] PRACK support in RTPENGINE module? > > > > I pushed a patch to rtpengine module to handle PRACK in both manage() > and answer() functions. > > Chris: can you test and see if works as expected? If yes, it will be > backported. > > Cheers, > Daniel > > On 04.05.20 19:51, Alex Balashov wrote: > > Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was > > part of a cascade of fixup functions that goes back to > > rtpengine_manage(), but not to _answer(). You're right of course. > > > > On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla > wrote: > > > >> Hello, > >> > >> Chris mentioned that rtpengine_answer() is also not supporting (or is > >> ruling out all request types but ACK), so the C code is limiting in > both > >> cases, no matter using rtpengine_manage() or rtpengine_answer(). > >> > >> The rtpengine manage() was built as a wrapper around offer()/answer() > >> and it makes the decision of which one is executed in various cases > >> (request/reply/failure route), but not what offer()/answer() functions > >> do internally. > >> > >> So in this case the code has to allow execution for PRACK, it was an > >> omission, likely not a scenario that popped up so far. > >> > >> Cheers, > >> Daniel > >> > >> On 04.05.20 19:22, Alex Balashov wrote: > >>> Hello Chris, > >>> > >>> rtpengine_manage() is just a wrapper that makes context-sensitive > >>> invocations of rtpengine_offer() and rtpengine_answer(), so that you > >>> don't have to choose which of them to call manually. But it's not > >>> perfect. > >>> > >>> There are nevertheless situations where this manual use of the > >>> offer/answer functions is necessary, and it sounds like this is one of > >>> them. > >>> > >>> There is a larger question of whether rtpengine_manage() should > support > >>> PRACK; it seems like the answer is yes. But this lacking cannot be > >>> framed as "RTPEngine doesn't support PRACK" or anything like that. > >>> RTPEngine can support any SDP-bearing request and reply, since > RTPEngine > >>> does not care about SIP semantics per se. > >>> > >>> -- Alex > >>> > >>> -- > >>> Alex Balashov | Principal | Evariste Systems LLC > >>> > >>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > >>> Web: http://www.evaristesys.com/ <http://www.evaristesys.com>, > http://www.csrpswitch.com/ <http://www.csrpswitch.com> > >>> > >>> _______________________________________________ > >>> Kamailio (SER) - Users Mailing List > >>> [email protected] <mailto:[email protected]> > >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> > >> -- > >> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> > >> www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > >> > >> > >> _______________________________________________ > >> Kamailio (SER) - Users Mailing List > >> [email protected] <mailto:[email protected]> > >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> > > -- > > Alex Balashov | Principal | Evariste Systems LLC > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, > http://www.csrpswitch.com/ <http://www.csrpswitch.com/> > > -- > Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> > www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] <mailto:[email protected]> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > *Disclaimer* > > Semafone is a limited company, registered in England, with registered > number 06963868. Our registered office is at Pannell House, Park > Street, Guildford, Surrey, GU1 4HN, United Kingdom. The information > contained in this communication from the sender is confidential. It is > intended solely for use by the recipient and others authorized to > receive it. If you are not the recipient, you are hereby notified that > any disclosure, copying, distribution or taking action in relation of > the contents of this information is strictly prohibited and may be > unlawful. If you have received this email in error, please send it > back to us, and immediately and permanently delete it. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast Ltd, an innovator in Software as a > Service (SaaS) for business. Providing a safer and more useful place > for your human generated data. Specializing in; Security, archiving > and compliance. To find out more Click Here > (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cudasvc.com) > Although Semafone has taken reasonable precautions to ensure no > viruses are present in this email, Semafone cannot accept > responsibility for any loss or damage sustained as a result of > computer viruses and the recipient must ensure that the email (and any > attachments) are virus free. > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
