Re: [reSIProcate] Implementing some proxy features alongside a DUM UA
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel