VoIP Mailing List Archives

[msc at freeswitch.org]

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> wrote:

[regs at kinetix.gr]

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:

[sicfslist at gmail.com]

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.



On Tue, Dec 9, 2008 at 9:19 AM, Apostolos Pantsiopoulos <regs@kinetix.gr (regs@kinetix.gr)> wrote:

[regs at kinetix.gr]

That approach introduces a third party application to
the setup (in order to capture and parse tha SIP messages)
that adds a lot in terms of complexity and reliability ( and cpu
usage). Also it could become a nightmare when you use a
mix of protocols (iax, sip, h323) and technologies (openzap etc).

In the case of a live debugging session, capturing is the most useful tool
but if you want to troubleshoot based on historical data (CDRs) then you
need some detailing. In addition you don't have to fill your databases
with all the fields that FS gives you in an XML cdr. You could
only pick those which are of interest in a particular application.



Shelby Ramsey wrote:

[regs at kinetix.gr]

That approach introduces a third party application to
the setup (in order to capture and parse tha SIP messages)
that adds a lot in terms of complexity and reliability ( and cpu
usage). Also it could become a nightmare when you use a
mix of protocols (iax, sip, h323) and technologies (openzap etc).

In the case of a live debugging session, capturing is the most useful tool
but if you want to troubleshoot based on historical data (CDRs) then you
need some detailing. In addition you don't have to fill your databases
with all the fields that FS gives you in an XML cdr. You could
only pick those which are of interest in a particular application.

Shelby Ramsey wrote:

[vhatz at kinetix.gr]

Shelby Ramsey wrote:

[regs at kinetix.gr]

That approach introduces a third party application to
the setup (in order to capture and parse tha SIP messages)
that adds a lot in terms of complexity and reliability ( and cpu
usage). Also it could become a nightmare when you use a
mix of protocols (iax, sip, h323) and technologies (openzap etc).

In the case of a live debugging session, capturing is the most useful tool
but if you want to troubleshoot based on historical data (CDRs) then you
need some detailing. In addition you don't have to fill your databases
with all the fields that FS gives you in an XML cdr. You could
only pick those which are of interest in a particular application.



Shelby Ramsey wrote:

[anthony.minessale at g...]

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 (vhatz@kinetix.gr)> wrote: