Re: [reSIProcate] Implementing some proxy features alongside a DUM UA
Hi Adam,
Yes, this totally makes sense.
Thanks for your reply,
Francis
On Sun, Aug 28, 2011 at 2:08 PM, Adam Roach <adam@xxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>