[SR-Users] Problem removing headers from FAILURE_ROUTE

Joel Serrano joel at gogii.net
Wed Oct 18 00:59:57 CEST 2017


Hi Brandon,

The problem is that I need to remove the headers only if we are going to
send the call outside of our platform, and that always happens after a
delivery try internally.

Something along:

Try 1: Caller (adds X- headers) --> Kamailio (forwards X- headers without
touching them) --> media srv (requires the X- headers that Caller added)
Try 2: If media srv rejects the call --> Hits failure_route in kamailio
---> We send to external server.

Now, in the first try (when we send the call to the media srv), we need the
headers, if that try fails, we then send the call to an external server,
and we don't want to send all the X- headers. Problem is, we are in the
failure_route at that point, so either it's too late or I'm not doing this
the way it has to be done.

I was thinking of trying:

1- remove the X-headers in request route
2- create a new branch_route and add them again in there
3- If required, remove them from failure route... (as they were added in
branch_route, maybe it works?)

Not 100% sure though...

What do you think?


Thanks!
Joel.


On Tue, Oct 17, 2017 at 12:43 PM, Brandon Armstead <brandon at cryy.com> wrote:

> Why do you not remove the headers in request_route {} ?
>
> Check and see where the call is uri or destination is going and add or
> remove as desired?
>
> On Tue, Oct 17, 2017 at 12:36 PM, Joel Serrano <joel at gogii.net> wrote:
> > Hi,
> >
> > After some research it all seems to come down to "you cannot remove
> headers
> > in failure_route that where added in request route".
> >
> > But, is there a way to remove headers in failure_route that came in the
> > initial INVITE? (so we didn't add anything, but we do want to remove
> before
> > sending out).
> >
> > Any ideas?
> >
> > Thanks,
> > Joel.
> >
> > On Fri, Oct 13, 2017 at 11:35 AM, Joel Serrano <joel at gogii.net> wrote:
> >>
> >> Hi all,
> >>
> >> I have the following scenario:
> >>
> >>
> >> Client -> Kamailio (adds X-CallSource hdr) -> Media Server -> Kamailio
> >> (removes all "X-" headers) -> Carrier
> >>
> >> Carrier doesn't get any X- headers. All works.
> >>
> >>
> >> Now for example, if the media server replies with a non-OK status, like:
> >>
> >> Client -> Kamailio (adds X-CallSource hdr) <-> Media Server (480
> >> Temporarily Unavailable)
> >>           Kamailio (in failure_route, removes all "X-" headers) ->
> >> External Voicemail Service
> >>
> >> External Voicemail Service gets the X- headers.
> >>
> >>
> >> Basically, on the first example, it is a regular call, all handled from
> >> request route.
> >>
> >> On the second example, call goes to media server, media server replies
> >> with a 480, reaches kamailio's failure route, in there we run the same
> >> remove_hf_re.
> >>
> >> In the captures I can see that the X-CallSource header (added at the
> very
> >> beginning) is still there.
> >>
> >>
> >> I have tried different combinations in the failure route:
> >>
> >> a) Tried removing exactly the header: remove_hf("X-CallSource")
> >> b) Tried removing any X- header: remove_hf_re("X-")
> >>
> >> Those didn't work, then I tried:
> >>
> >> c) append_hf("X-CallSource: Test")
> >>     remove_hf("X-CallSource")
> >>
> >> The result was now two X-CallSource headers, the add worked, the remove
> >> didn't.
> >>
> >> I thought maybe "msg_apply_changes()" could help, but it isn't valid
> >> inside failure_route.
> >>
> >>
> >>
> >> So what is the deal here? Am I doing something completely wrong or is it
> >> just that you cannot remove headers (but you can add) in failure route?
> >> According to the doc:
> >>
> >>
> >> https://www.kamailio.org/docs/modules/devel/modules/textops.
> html#textops.f.remove_hf_re
> >> -----> This function can be used from ANY_ROUTE.
> >>
> >> OS: Debian 8
> >> Kamailio: 4.4.5 (installed from deb repo)
> >>
> >> # kamailio -v
> >> version: kamailio 4.4.5 (x86_64/linux)
> >> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE,
> >> USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC,
> >> TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> >> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
> >> HAVE_RESOLV_RES
> >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> >> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> >> id: unknown
> >> compiled with gcc 4.9.2
> >>
> >>
> >> Any suggestions?
> >>
> >> Thanks
> >> Joel.
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
>
>
> --
> Sincerely,
> Brandon Armstead
> CTO / CRYY.com
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171017/fbf6ed03/attachment.html>


More information about the sr-users mailing list