[SR-Users] Altering received parameter in Contact
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jan 30 13:55:19 CET 2019
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
On 30.01.19 03:27, David Cunningham wrote:
> Great, thanks for letting me know.
>
>
> On Wed, 30 Jan 2019 at 13:10, Alex Balashov <abalashov at evaristesys.com
> <mailto:abalashov at 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 at voisonics.com <mailto:dcunningham at 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 at evaristesys.com <mailto:abalashov at 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 at 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 at lists.kamailio.org
> <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190130/0e6b4012/attachment.html>
More information about the sr-users
mailing list