see this is better. That's why I asked you to be more specific about what you want because the tiny back and forth questions were not exposing your intent or needs at all. I answer every email I can and when threads start to grow without getting to the point i start to get frustrated. Now that you have opened up the discussion you have more people chiming in on the topic. Yes the sip_* variables are unique to SIP and the one that says proto_specific are all done per implementation. If you would like to suggest a list of standard variables you think apply to all calls or something you feel is missing, we can consider injecting them into the code. On Tue, Dec 9, 2008 at 10:42 AM, Vlasis Hatzistavrou (KTI) <vhatz@kinetix.gr
wrote:
Shelby Ramsey wrote:
Hello,
This is just my 2 cents ... but my experience has been that trying to catch all of the various variables (i.e. from XML_CDR) or otherwise can be a little trying (a row in your CDR database could be over 100 fields long!).
The best option here is to catch the UUID's for the 2 call legs, capture all SIP messaging, parse and dump the messaging, and then correlate the calls from the CDR from there.
Much easier than trying to do it from FS ... and most folks want to see SIP captures anyway (very broad set of tools to debug).
Measuring things like ASR, PDD, etc in my opinion is much easier from the raw messaging than trying to do something with FS CDR records.
That can certainly be an option, especially for debugging purposes.
However, under heavy load (imagine a few thousands of calls per hour, a few millions per day) logging and parsing all the SIP messages on file will be a problem.
Also, logging SIP messages is oriented to SIP only, when a more protocol agnostic approach could be followed. Plus, we would still need to parse a lot of text to extract the information that we need, while in a CDR (even a long one with many fields) we have a lot of information with a minimum hassle.
We've seen in production environments that excessive logging wastes I/O power and disk space, this is why (we at least) turn it on in our various systems only when we need it for troubleshooting, and immediately turn it off afterwards.
Additionally, a very long CDR is a lot less text to write on disk once, after the call is over, rather than writing many, whole packets during the duration of a call.
A 100-field-CDR on file could not be much of a problem, because usually these the raw CDR fields are rarely imported in a database in their entirety for billing or QoS analysis. A lot of the information which is not used directly & immediately for billing or QoS analysis remains on file in case needs to do basic troubleshooting in arrears. Granted, we would not have the same amount of information as with the written SIP messages, but it is useful nonetheless.
Of course, I need to stress that I write all this coming from the background of VoIP carriers. The above could apply well for typical & simple scenarios, where a call leg comes into FS and another calls leg comes out of it, which is what most carriers do.
If we need billing and QoS analysis for IVR's, queues, call transfers, etc, then yes, one-line CDRs would not do. In this case, logging whole packets could be a solution, although an event-based approach could be much better to cover all protocols/technologies (IAX, TDM cards, etc), IMHO.
Best regards, Vlasis Hatzistavrou Kinetix Tele.com Hellas Ltd. Monastiriou 9 & Enotikon 54627 Thessaloniki Greece Tel.: +302310556134 Fax: +302310556134 (ext. 0) GSM: +306977835653 e-mail: vhatz@kinetix.gr http://www.kinetix.gr
On Tue, Dec 9, 2008 at 9:19 AM, Apostolos Pantsiopoulos <regs@kinetix.gr <mailto:regs@kinetix.gr>> wrote:
We are currently in the migration process from our current system to a FS based setup. We are in the process of adapting our billing and routing to FS. All the CDRs (and variables) related issues that we have been discussing on this mailing list come from the need to extract the same level of information from FS
as
we do with our current closed source proprietary system. So, we chose FS because of the versatility it provides in every aspect
(event
handling, config implementation etc.) and we strongly believe that
all
these additions/fixes would be beneficial to many potential FS users.
We are at your disposal for more details in case you need more information about what exactly we are trying to do. Basically, our approach is from the VoIP carrier's point of view rather than the PBX user's/implementor's. So, the details that we asked to be
introduced
to FS come from real life issues that we have faced during the last few years with various platforms and troubleshooting experiences with other VoIP carriers.
Michael Collins wrote:
Thanks for your feedback. It definitely helps to know not only what you need FS to do but why you need it to do so.
Do you have FS in production right now? Just curious.
Thanks, MC
On Tue, Dec 9, 2008 at 12:21 AM, Apostolos Pantsiopoulos <regs@kinetix.gr> <mailto:regs@kinetix.gr> wrote:
"I already added 2 patches for you right. Just be clear about what
you
want."
And I am grateful of that.
"it is protocol neutral, that's why it starts with sip_"
I didn't know that. I thought that the sip_ variables are protocol
specific.
So one would expect there to be an iax_hangup_disposition, woomera_hangup_disposition etc?
"Maybe you should beat around the bush less with your
"requirements" for
your application you are expecting me to support for you."
I am just trying to gather statistics for my providers as I would
with any
VoIP softswitch. (hangup causes per terminator per destination) I don't think that this is a specific "application" rather than a
general
necessity for VoIP carriers. It is also very useful for
troubleshooting
purposes : when I look at my CDRs to find a call that I got a
complain for,
I want to be able to tell if it was me or the provider who hanged up and gave a specific hangup cause, so that I can
troubleshoot the
issue better.
"Just be clear about what you want."
I want FS to reach that level of detailing and maturity in all
aspects so
that it could be the softswitch of choice by any VoIP entrepreneur (or hobbyist) and it is my strong belief that this can only be done
by the
community giving feedback to the programmers about what they find useful or not (i.e. experience from real-life
situations). The
patches that you made the last few days were not intended for me exclusively but for anyone that will face the same situations
using FS.
If you want the community to stop sending feedback about features/improvements you may as well close down this mailing list
or just
use it as an announcement board.
I wish I was a c programmer and get involved with the project
actively. But
I am not. And as far as I can tell most of the registered users in this list aren't either. So they only way we can help is by
testing and
suggesting.
Anthony Minessale wrote:
it is protocol neutral, that's why it starts with sip_
the variable can be any of:
send_bye recv_bye send_cancel send_refuse
using that value you can determine the information you asked. I
answered
your specific question which was: determining "which side hanged up". Maybe you should beat around
the bush
less with your "requirements" for your application you are
expecting me to
support for you.
I already added 2 patches for you right. Just be clear about what
you want.
On Mon, Dec 8, 2008 at 8:13 AM, Apostolos Pantsiopoulos <
regs@kinetix.gr> <mailto:regs@kinetix.gr>
wrote:
Not necessarily. For instance I got a "send_cancel" when the calling party hanged up before the other party could pick up. Also, shouldn't something like that be protocol/technology neutral?
Anthony Minessale wrote:
sip_hangup_disposition will be set to recv_bye on the side that
was
hungup.
On Mon, Dec 8, 2008 at 4:11 AM, Apostolos Pantsiopoulos <
regs@kinetix.gr> <mailto:regs@kinetix.gr>
wrote:
Any updates about the "which side hanged up" potential variable?
Michael S Collins wrote:
Makes sense. I will look into this. -MC
On Dec 5, 2008, at 8:17 AM, Apostolos Pantsiopoulos <
regs@kinetix.gr> <mailto:regs@kinetix.gr>
wrote:
I am sending this second email to request/suggest/enquire about
something
relevant :
Wouldn't it be useful to know which end of a specific call leg
send the
protocol specific hangup cause? Otherwise it would be difficult to
understand what
really happened.
Michael S Collins wrote:
I will do some research on this and let you know what I find out. Question: are these internal calls or pstn or ?? Just curious
about
your environment.
Thanks, MC
On Dec 5, 2008, at 4:23 AM, Apostolos Pantsiopoulos <
regs@kinetix.gr> <mailto:regs@kinetix.gr>
wrote:
The proto_specific_hangup_cause is missing on one of the two call legs. When the caller hangs up it is missing from the a-leg
CDR.
When the callee hangs up it is missing from the b-leg CDR. Is
this
nornal?
And another question : what piece of info could inform me about
who
hanged up?
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr <mailto:regs@kinetix.gr> -------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr <mailto:regs@kinetix.gr> -------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
________________________________ _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr <mailto:regs@kinetix.gr> -------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com<MSN%3Aanthony_minessale@hotmail.com><mailto: MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com><mailto: GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <mailto:iax:
guest@conference.freeswitch.org/888>
googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org><mailto:
googletalk:conf+888@conference.freeswitch.org<conf%2B888@conference.freeswitch.org>
pstn:213-799-1400
________________________________ _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr <mailto:regs@kinetix.gr> -------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com<MSN%3Aanthony_minessale@hotmail.com><mailto: MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com><mailto: GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <mailto:iax:
guest@conference.freeswitch.org/888>
googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org><mailto:
googletalk:conf+888@conference.freeswitch.org<conf%2B888@conference.freeswitch.org>
pstn:213-799-1400
________________________________ _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr <mailto:regs@kinetix.gr> -------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:
Freeswitch-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto: Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr <mailto:regs@kinetix.gr> -------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400