[reSIProcate] Implementing some proxy features alongside a DUM UA

[Scott Godin]

The current MessageFilterRuleList (TuSelector) allows you to route to a
particular TU based on more than just the method type.  Check out
MessageFilterRule::matches.  Can you make use of the existing rules, or
extend the rules to suit your needs, so that you select the one correct TU
using this method, instead of trying to route a message to two different
TU's?

Scott

On Mon, Aug 15, 2011 at 10:09 AM, Francis Joanis
<francis.joanis at gmail.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110828/f8ab559d/attachment.htm>