[Freeswitch-users] Proto specific hangup cause issue
Anthony Minessale
anthony.minessale at gmail.com
Tue Dec 9 09:08:51 PST 2008
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 at 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 at kinetix.gr
> http://www.kinetix.gr
>
>
>
> >
> >
> >
> > On Tue, Dec 9, 2008 at 9:19 AM, Apostolos Pantsiopoulos <regs at kinetix.gr
> > <mailto:regs at 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 at kinetix.gr> <mailto:regs at 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 at kinetix.gr> <mailto:regs at 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 at kinetix.gr> <mailto:regs at 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 at kinetix.gr> <mailto:regs at 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 at kinetix.gr> <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
> >>>>> -------------------------------------------
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Freeswitch-users mailing list
> >>>>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at kinetix.gr <mailto:regs at kinetix.gr>
> >>>>> -------------------------------------------
> >>>>>
> >>>>> _______________________________________________
> >>>>> Freeswitch-users mailing list
> >>>>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at kinetix.gr <mailto:regs at kinetix.gr>
> >>>>> -------------------------------------------
> >>>>>
> >>>>> _______________________________________________
> >>>>> Freeswitch-users mailing list
> >>>>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com><mailto:
> MSN:anthony_minessale at hotmail.com>
> >>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com><mailto:
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> >
> >>>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
> >>>>
> >>>> FreeSWITCH Developer Conference
> >>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
> >>>> iax:guest at conference.freeswitch.org/888 <mailto:iax:
> guest at conference.freeswitch.org/888>
> >>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org><mailto:
> googletalk:conf+888 at conference.freeswitch.org<conf%2B888 at conference.freeswitch.org>
> >
> >>>> pstn:213-799-1400
> >>>>
> >>>> ________________________________
> >>>> _______________________________________________
> >>>> Freeswitch-users mailing list
> >>>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at kinetix.gr <mailto:regs at kinetix.gr>
> >>>> -------------------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> Freeswitch-users mailing list
> >>>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com><mailto:
> MSN:anthony_minessale at hotmail.com>
> >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com><mailto:
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> >
> >>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
> >>>
> >>> FreeSWITCH Developer Conference
> >>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
> >>> iax:guest at conference.freeswitch.org/888 <mailto:iax:
> guest at conference.freeswitch.org/888>
> >>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org><mailto:
> googletalk:conf+888 at conference.freeswitch.org<conf%2B888 at conference.freeswitch.org>
> >
> >>> pstn:213-799-1400
> >>>
> >>> ________________________________
> >>> _______________________________________________
> >>> Freeswitch-users mailing list
> >>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at kinetix.gr <mailto:regs at kinetix.gr>
> >>> -------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Freeswitch-users mailing list
> >>> Freeswitch-users at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at lists.freeswitch.org <mailto:
> Freeswitch-users at 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 at kinetix.gr <mailto:regs at kinetix.gr>
> > -------------------------------------------
> >
> >
> > _______________________________________________
> > Freeswitch-users mailing list
> > Freeswitch-users at lists.freeswitch.org
> > <mailto:Freeswitch-users at 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 at 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 at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20081209/c88316a7/attachment-0002.html
More information about the FreeSWITCH-users
mailing list