Adam Long napsal(a):
MySQL MEMORY/HEAP table might be ideal for this. This data is prob not critical and is probably being used for diagnosing peer connectivity issues anyway. If it is critical well then... there are always trade offs right :)
Thank you very much, Adam, for interest! You are right - it is for diagnosis. And while the data is not critical, I can't leave them in MySQL MEMORY table. Based on my counts I have to store and maintain about 70-90 GiB of SIP messages and I simply don't have enough RAM :-)
I think in general what he is speaking of is just some sort of temporary SIP trace setup that can log that can be controlled or filtered. So its not just all or nothing.
Exactly! :-)
I wonder is it possible to enable the current sip trace functionality via a variable. For example something like this.
<action application="bridge" data="{sip_trace=on}sofia/public/XXXXXXXXXX@10.10.10.1" /> This of course only helps for bridged B2BUA calls.
It will be very helpful...
But if inbound sip tracing is required a user param like sip_trace could address that, yes?
Yes, I need all SIP packets except nat-keep-alives... BTW: How to recognize them? I know how could I do it on proxy (SER like), but what about on FreeSWITCH? Anyway - for me it shouldn't be an issue, because I filter then on loadbalancer.
That could be a good starting point, then perhaps I could help roll a mod_xml_siptrace module based on the mod_xml_cdr design/concept that could somehow link into the existing sip trace logging.
It will be very powerfull, but I'm affraid it can't scale to thousands request per second.
Just some thoughts, no idea how much of this exists today.
Thanks once more, Adam! Best regards, kokoska.rokoska