[reSIProcate] Implementing some proxy features alongside a DUM UA

[Adam Roach]

Unless your logic for determining what should be proxied is extremely 
complex, the CPU load that results from calling isForMe() on the proxy 
for each request will be too small to make a difference.

Really. Profile your application and see where your time is going. This 
won't be.

/a

On 8/15/11 09:09, Aug 15, Francis Joanis wrote:
> Hi guys,
>
> Let's say I have a DUM instance (thus a UA) that would require to
> _sometimes_ process request as if it were a proxy. For example:
>
> - When the UA application receives a request that is meant (by R-URI
> and To, for example) to reach it, it should process it normally using
> DUM
>
> - When the UA application receives a request that wasn't meant to
> reach it (for whatever reason), assuming the application knows where
> to find the real target (for example, if it shared a registration
> table, ...), then it should act as a proxy and proxy the request to
> the real target
>
> In this case the same request methods would need to be supported both
> in the UA scenario (DUM) and in the "proxy" scenario (for example,
> INVITE).
>
> Off the top of my head, this might be possible using:
>
> - Registering 2 transaction users (TUs), one for the the "proxy" and
> one for DUM and ensuring that the proxy TU always has precedence over
> the DUM one. That way, when it receives a request it would be able to
> query the application to know if it should proxy it or let if fall
> through the DUM TU. This would require writing an overloaded
> TransactionUser::isForMe method for the proxy. What I don't like in
> this case is that the proxy TU will always be in the "code path" even
> for regular DUM calls.
>
> - Another way would be to still use the two TUs, but make the DUM have
> precedence over the proxy one and have a way for an application to
> overload the default TransactionUser::isForMe mechanism.
>
> I think I prefer the second option, but I also think my fears of
> always having the proxy TU in the code path might not totally make
> sense: in both cases, every transaction (from the SipStack) will end
> up calling isForMe, but since the DUM would be before the proxy TU in
> the TU list, it might save some CPU cycles ;)
>
> What do you think?
>
> Regards,
> Francis
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel