[reSIProcate] (DUM) Best way to log details about a failed validation on an incoming request
Francis Joanis
francis.joanis at gmail.com
Thu Feb 24 13:51:18 CST 2011
Thanks Scott, I'll give it a shot when I get some cycles.
What is the ETA for resip 1.7? I remember seeing some messages but I think
we are past the previous dates.
Thanks,
Francis
On Tue, Feb 22, 2011 at 11:33 AM, Scott Godin <sgodin at sipspectrum.com>wrote:
> I like the 2nd option as well. If a handler is not defined/set, then the
> existing code can run as is - the only additional work would be checking if
> there is a customer handler defined or not.
>
> Scott
>
> On Mon, Feb 21, 2011 at 10:07 AM, Francis Joanis <francis.joanis at gmail.com
> > wrote:
>
>> Hi guys,
>>
>> I would like to log (using my application event log, so not the same as
>> the resip logger) when a validation fails when an incoming request is
>> received by the DUM.
>>
>> For example, if an unsupported method is received I would like to log:
>>
>> - The method that was unsupported
>> - Who was the sender (i.e. where this message comes from - Tuple, ...)
>> - Maybe other interesting things about the message as well...
>>
>> The closest I got to was by having my own MasterProfile::isMethodSupported
>> method (so by subclassing it) but that only gave me the MethodType and not
>> the SipMessage itself.
>>
>> Also, looking at the code that calls the various validation methods in the
>> DUM, not all validators end up calling a "is*Supported" in the
>> MasterProfile. For example, DialogUsageManager::validateRequiredOptions only
>> gets the list of unsupported options from the profile and thus wouldn't
>> enable overloading like MasterProfile::isMethodSupported did.
>>
>> I currently see two options:
>>
>> - Extend what is in MasterProfile so that the validation is actually
>> performed in there. That would enable subclassing and hooking into the
>> validation chain...
>> - Add a new handler to the DUM, like a MessageValidationHandler, that
>> would expose behaviors like onIncomingFailed, ...
>>
>> I prefer the second option, but would like to know what you think :)
>> Hopefully adding a new handler wouldn't hinder performance too much.
>>
>> Thanks,
>> 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/20110224/750bbac7/attachment.htm>
More information about the resiprocate-devel
mailing list