[SR-Users] Kamailio Iterate All Headers

Daniel-Constantin Mierla miconda at gmail.com
Fri Jul 1 10:10:51 CEST 2016


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
> <abalashov at evaristesys.com <mailto: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
>     <http://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 <mailto:sr-users at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160701/15cb3b08/attachment.html>


More information about the sr-users mailing list