Re: [reSIProcate] repro updating request URI
If you use ;lr on your targets then a route header will be added instead of
modifying the request uri. You can use this on route destinations on the web
page.
I've always thought that it would be nice to make this more obvious by adding a
loose routing check box to the route web page that defaults to enabled.
Scott
Sent from my iPhone
> On Nov 11, 2016, at 9:16 AM, Daniel Pocock <daniel@xxxxxxxxxx> wrote:
>
>
>
> Looking at the way repro currently operates:
>
>
> - the original request URI is accessed (and can be modified) through
>
> RequestContext::getOriginalRequest().header(resip::h_RequestLine).uri()
>
>
> - monkey classes don't seem to modify this, instead, they simply add
> targets using
>
> RequestContext::getResponseContext().addTarget(foo)
>
>
> - if a route is used to re-write an address on the same host (e.g.
> changing sip:help@xxxxxxxxxxx to sip:user1@xxxxxxxxxxx) or to change the
> domain before it hits the Location service (e.g. from
> sip:user@xxxxxxxxxxxxxxxx to sip:user@xxxxxxxxxxx) then a new message is
> sent out over the network and comes back in over the network to be
> processed from the beginning of the chain. This causes various
> problems, e.g. the looped-back request may not pass authentication
> unless the proxy is configured to identify requests that loop back like
> this.
>
>
> - SER-based SIP proxies (e.g. Kamailio) are modifying the request URI as
> the request passes through their routing logic
>
>
> - should we have a mutable request URI field in the RequestContext? It
> would be initialized from the incoming request but any monkey could read
> it and/or change it.
>
>
> - this could potentially be used for the forwardAddress field in the
> user table
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel