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 -------------------------------------------
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> 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 -------------------------------------------
_______________________________________________ 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
Both legs are SIP. From non-registered endpoints (if of any use). 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> 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 -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
It's easy enough to set the value on both legs try r10614 It was only set on the opposing leg before but since it's harmless to set it on both i did it for you. On Fri, Dec 5, 2008 at 10:23 AM, Brian West <brian@freeswitch.org> wrote:
Did you say what SVN rev you're running.
/b
On Dec 5, 2008, at 10:11 AM, Apostolos Pantsiopoulos wrote:
Both legs are SIP. From non-registered endpoints (if of any use).
_______________________________________________ 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
I tested it and it works fine but it got me thinking... Is just a copy of the cause to the other leg the correct way to do it? Couldn't the two call legs hang up with different causes? Especially when I could override the cause before it got send to the e.g. calling side using e.g. the hangup command? To make myself clear : I could have the b-leg (in a bridge hangup) sending me a user busy code and I could send a circuit/channel unavailable to my caller (a-leg), let's say because I don't trust my terminator (b-leg) and his codes and I want to enforce another one and send it to my originator so that he could retry another carrier. What do you think? Anthony Minessale wrote:
It's easy enough to set the value on both legs try r10614 It was only set on the opposing leg before but since it's harmless to set it on both i did it for you.
On Fri, Dec 5, 2008 at 10:23 AM, Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>> wrote:
Did you say what SVN rev you're running.
/b
On Dec 5, 2008, at 10:11 AM, Apostolos Pantsiopoulos wrote:
> Both legs are SIP. From non-registered endpoints (if of any use).
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 ------------------------------------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
This variable is to specifically document the protocol specific last status cause. So you can know what the status was when you got a BYE or final response to invite in the case of sip. That's all it's for. On Fri, Dec 5, 2008 at 12:43 PM, Apostolos Pantsiopoulos <regs@kinetix.gr>wrote:
I tested it and it works fine but it got me thinking...
Is just a copy of the cause to the other leg the correct way to do it? Couldn't the two call legs hang up with different causes? Especially when I could override the cause before it got send to the e.g. calling side using e.g. the hangup command?
To make myself clear : I could have the b-leg (in a bridge hangup) sending me a user busy code and I could send a circuit/channel unavailable to my caller (a-leg), let's say because I don't trust my terminator (b-leg) and his codes and I want to enforce another one and send it to my originator so that he could retry another carrier.
What do you think?
Anthony Minessale wrote:
It's easy enough to set the value on both legs try r10614 It was only set on the opposing leg before but since it's harmless to set it on both i did it for you.
On Fri, Dec 5, 2008 at 10:23 AM, Brian West <brian@freeswitch.org> wrote:
Did you say what SVN rev you're running.
/b
On Dec 5, 2008, at 10:11 AM, Apostolos Pantsiopoulos wrote:
Both legs are SIP. From non-registered endpoints (if of any use).
_______________________________________________ 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
------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
FreeSWITCH Version 1.0.trunk (10579) Brian West wrote:
Did you say what SVN rev you're running.
/b
On Dec 5, 2008, at 10:11 AM, Apostolos Pantsiopoulos wrote:
Both legs are SIP. From non-registered endpoints (if of any use).
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
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> 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 -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
Makes sense. I will look into this. -MC On Dec 5, 2008, at 8:17 AM, Apostolos Pantsiopoulos <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> 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 -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr ------------------------------------------- _______________________________________________ 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
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 http://www.freeswitch.org
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
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>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> 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>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 -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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 listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
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 < <mailto:regs@kinetix.gr>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 http://www.freeswitch.org
_______________________________________________ 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 <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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 ------------------------------------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
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>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>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> 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>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 -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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 listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
"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 < <mailto:regs@kinetix.gr>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 http://www.freeswitch.org
_______________________________________________ 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 <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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%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 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 ------------------------------------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
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:
"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> 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> 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> 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> 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 -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
________________________________ _______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
________________________________ _______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
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> 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> 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> 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> 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> 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 -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
________________________________ _______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
________________________________ _______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
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>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> <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> <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> <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> <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> <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 -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
________________________________ _______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthmMSN:anthony_minessale@hotmail.comGTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conferencesip:888@conference.freeswitch.orgiax:guest@conference.freeswitch.org/888googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
________________________________ _______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthmMSN:anthony_minessale@hotmail.comGTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conferencesip:888@conference.freeswitch.orgiax:guest@conference.freeswitch.org/888googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
________________________________ _______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_______________________________________________ Freeswitch-users mailing listFreeswitch-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs@kinetix.gr -------------------------------------------
_______________________________________________ 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
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:
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 <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 http://www.freeswitch.org
_______________________________________________ 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 <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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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 <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
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:
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 <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 http://www.freeswitch.org
_______________________________________________ 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 <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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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 <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
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:
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 <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 http://www.freeswitch.org
_______________________________________________ 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 <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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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 <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
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 http://www.freeswitch.org
_______________________________________________ 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 <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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN:anthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 <mailto:iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk:conf+888@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 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 <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
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
participants (8)
-
Anthony Minessale
-
Apostolos Pantsiopoulos
-
Brian West
-
Michael Collins
-
Michael S Collins
-
regs＠kinetix.gr
-
Shelby Ramsey
-
Vlasis Hatzistavrou (KTI)