Callum, Unfortunately, the contact information and parameters are read-only and cannot be set using a transformation. I've also tried fix_nated_contact and it appends an additional expire parameter to the end of the contact header. As such, I end up with, expires=486;expires=60.
- Joe On Fri, Mar 12, 2021 at 5:41 AM Callum Guy <callum....@x-on.co.uk> wrote: > Hi Joseph, > > I haven't fully digested your scenario however you may have some luck > using the nathelper function fix_nated_contact - presuming NAT is not an > issue. > > > https://opensips.org/html/docs/modules/3.1.x/nathelper.html#func_fix_nated_contact > > Otherwise you'll probably be able to achieve this using general > transformations, should be quite straightforward if you only have a single > Contact: > > https://www.opensips.org/Documentation/Script-Tran-3-1#toc60 > > Hope that helps, > > Callum > > > On Fri, 12 Mar 2021 at 03:55, Joseph Barrero <joebarr...@gmail.com> wrote: > >> Is there a way to replace the expires parameter in a Contact header >> within a reply route? >> >> The issue I'm trying to solve is the following. >> >> I have two OpenSIPS servers, a primary and a backup. The OpenSIPS server >> is performing mid-registrar duties for Freeswitch. However, when I take >> the primary OpenSIPS server down for maintenance and bring it back online, >> Freeswitch still has the other registration active. When the UA tries to >> register again on the primary OpenSIPS server, the mid-register module >> sends a request over to Freeswitch, and Freeswitch returns two contacts; >> one contact with the modparam("mid_registrar", "outgoing_expires", 600) >> value and the other contact with an expiration of whatever value it happens >> to be on (in this example it is 600 - time elapsed) from the registration >> created by the secondary OpenSIPS server. >> >> The problem is that the expiration parameter in the 200 Ok reply to the >> UA from OpenSIPS on a successful registration has the second expiration >> value instead of the shorter expiration value set in >> modparam("mid_registrar", "max_expires", 60). >> >> The result, is that the UA goes from 60-second registrations to whatever >> the second expiration value had at the time (a value between 0 and 599). >> When the second expiration is higher than 60 seconds, the UA's registration >> is expired on OpenSIPS for up to 599 seconds. >> >> What I'd like to do is simply change the expire parameter in the contact >> header to 60 seconds on the reply route. >> >> Any help will be greatly appreciated. >> >> Thank you, >> Joe Barrero >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > *0333 332 0000 | x-on.co.uk <https://www.x-on.co.uk> | ** > <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> > <https://twitter.com/xonuk> ** | Coronavirus > <https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>** > | Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>* > > THE ITSPA AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks > of the Internet Telephony Services Providers' Association, used under > licence. > > *From April 1st 2021 our office address will change to: Units 22-24 Riduna > Park, Melton IP12 1QT.* > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. > Views > or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users