[SR-Users] Kamailio Iterate All Headers

[Colin Morelli]

I suppose there's a lot of subjectivity here - and it greatly depends on
your configuration - but at least for my use case I don't quite agree with
that statement. My API is already the component performing authentication
and making routing decisions anyway, which means Kamailio is going to send
the SIP traffic to wherever it says. Pushing a full list of headers to that
endpoint doesn't compromise security any more than it already is by
allowing the API to decide where that SIP message goes next. (In other
words: my API is controlling SIP credentials, and if it really wanted
access to the value of another header, it could simply redirect the SIP
request to a server it controls).

Additionally, this means that if I need to change the routing decisions
that my API makes, I have to redeploy Kamailio with configuration changes
to send the new header values. This leaks implementation details of my API
into a layer that really doesn't need (or want) to concern itself with that
work.

Again - I fully understand that everyone's solutions here are different and
this is just how it applies in my particular scenario. So I'm not intending
to argue here, rather just suggesting that there are some valid use cases
for it.

In any case, thanks for the response! I'm sure I'll be back with more
questions as I continue to work through this.

Best,
Colin

On Mon, Jun 27, 2016 at 8:00 AM Alex Balashov <abalashov at evaristesys.com>
wrote:

> FWIW, I think that from a security and software quality perspective,
> explicitly defining which headers you want to feed to the API is the much
> better approach anyway.
>
> -- Alex
>
> --
> Principal, Evariste Systems LLC (www.evaristesys.com)
>
> Sent from my Google Nexus.
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160627/be3c8033/attachment.html>