Hello,
you can get the only the headers from sip message in the following way:
- compute the length of the sip message without the body (there are
variables for message buffer len and body size, or use the s.len
transformation)
- use substring transformation over $mb to get only its first part of
length size computed at the previous step
If you want to skip the first line and have only pure headers, then use
{line.at,0) transformation over the above result to get the first line,
then compute its length and again substring to skip it.
For convenience, in the devel master branch I added a new variable
$msg(hdrs) which returns only the headers.
I am also considering to add an iterator to be able to walk through
headers. That is even possible now by using {line.at,pos} and
{s.select,...}, but with a bit more scripting inside the config file.
Cheers,
Daniel
On 27/06/16 14:10, Colin Morelli wrote:
> 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
> <abalas...@evaristesys.com <mailto:abalas...@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
> <http://www.evaristesys.com>)
>
> Sent from my Google Nexus.
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
