Actually I am a bit more skeptical than Alex on this one and I tend to say that messing with that avp value it is a wrong approach.
The value of the received_avp is saved in the location table and used later for sending traffic to that device, so if you remove the transport from there, practically you make Kamailio to use UDP instead of the correct transport, even if that transport is still in the contact address -- obviously, traffic will fail to be routed to the device unless the device is listening on same port for UDP.
More than that, when building the Contact headers for 200ok of REGISTER, the value might not be taken from the avp, but from the location table records. For sure that is done in case the user has many devices, because the 200ok has all the Contacts of that device, not only the one for that specific REGISTER request (this is required by SIP specs).
Because I haven't developed this part of the code, I cannot say for sure, but again, it is my expectation based on SIP specs and what is done during save() and lookup() of location records.
So I strongly recommend at least to test properly before deploying to production or look at the related C code in registrar and usrloc modules to confirm the behaviour you expect.
What is for sure is that by setting the modparam received_param to empty, the received parameter is not added to Contact headers of 200ok. It is not impacting at all what Kamailio has to do internally during save() location.
The parameter for received_avp is for telling to kamailio what variable to use to store a string build from source ip/port/proto for some operations during save().
Cheers,
Daniel
Great, thanks for letting me know.
On Wed, 30 Jan 2019 at 13:10, Alex Balashov <abalashov@evaristesys.com> wrote:
I don't see any issues with it, no...
On Wed, Jan 30, 2019 at 01:06:40PM +1300, David Cunningham wrote:
> Hi Alex,
>
> We already had this line in our kamailio.cfg:
> modparam( "nathelper|registrar", "received_avp", "$avp(RECEIVED)" )
>
> We do need to change the received parameter conditionally depending on the
> user agent, and the following seems to work:
> if ( $ua =~ "ewb2bua" ) {
> avp_subst( "$avp(RECEIVED)", "/(.*);transport=TLS/\1/i" );
> }
>
> Can you see any issues with this?
>
> Thank you!
>
>
> On Wed, 30 Jan 2019 at 10:50, David Cunningham <dcunningham@voisonics.com>
> wrote:
>
> > Hello everyone who replied, and thank you for your advice! We will try the
> > suggestions given.
> >
> >
> > On Wed, 30 Jan 2019 at 01:34, Alex Balashov <abalashov@evaristesys.com>
> > wrote:
> >
> >> Hi David,
> >>
> >> Well, the registrar's 200 OK should include the very Contact binding
> >> that was stored for the given AOR, and for a TLS registrant, that's
> >> going to unavoidably contain the ;transport=TLS attribute, because TLS
> >> is not the default presumed transport in the absence of a ;transport
> >> attribute.
> >>
> >> If the issue is specifically with the occurrence of ;transport=TLS in
> >> the 'received' parameter, that can be modulated here:
> >>
> >>
> >> https://kamailio.org/docs/modules/5.2.x/modules/registrar.html#registrar.p.received_param
> >>
> >> And if it needs to be controlled on a situational/per-registration
> >> basis, one can use the AVP:
> >>
> >>
> >> https://kamailio.org/docs/modules/5.2.x/modules/registrar.html#registrar.p.received_avp
> >>
> >> If you set it to empty for a registration from a certain type of device,
> >> the parameter will not be populated and thus not reflected back to the
> >> registering UA.
> >>
> >> -- Alex
> >>
> >> On Tue, Jan 29, 2019 at 03:28:38PM +1300, David Cunningham wrote:
> >>
> >> > Hello,
> >> >
> >> > I'm hoping someone can give advice on altering the received parameter in
> >> > the Contact header on a reply. The situation is that a customer is
> >> > REGISTERing using TLS, and our Kamailio replies with a 200 OK that
> >> includes
> >> > a Contact header like this:
> >> >
> >> > Contact: <sip:123456789@xx.xx.102.10
> >> >
> >> :5061;transport=tls>;expires=3600;received="sip:xx.xx.102.10:36051;transport=TLS"
> >> >
> >> > The customer's device apparently had an issue with this, and the device
> >> > manufacturer advises that they need the ";transport=TLS" on the received
> >> > parameter removed. This sounds like a strange requirement, but it's what
> >> > we've been told. Does anyone know how to alter this in a Kamailio
> >> > configuration?
> >> >
> >> > Our system uses www_authorize to authenticate and is running Kamailio
> >> 4.2.1.
> >> >
> >> > Thanks in advance for any help!
> >> >
> >> > --
> >> > David Cunningham, Voisonics Limited
> >> > http://voisonics.com/
> >> > USA: +1 213 221 1092
> >> > New Zealand: +64 (0)28 2558 3782
> >>
> >> > _______________________________________________
> >> > Kamailio (SER) - Users Mailing List
> >> > sr-users@lists.kamailio.org
> >> > 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.csrpswitch.com/
> >>
> >> _______________________________________________
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >
> >
> > --
> > David Cunningham, Voisonics Limited
> > http://voisonics.com/
> > USA: +1 213 221 1092
> > New Zealand: +64 (0)28 2558 3782
> >
>
>
> --
> David Cunningham, Voisonics Limited
> http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> 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.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com