Re: [reSIProcate] Implementing some proxy features alongside a DUM UA
Hi Scott,
Thanks for the pointer to MessageFilterRule, I'll give it a try.
Thanks again,
Francis
On Sun, Aug 28, 2011 at 12:22 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
> 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
>
>