VoIP Mailing List Archives

[regs at kinetix.gr]

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

[msc at freeswitch.org]

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:

[regs at 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:

[brian at freeswitch.org]

Did you say what SVN rev you're running.

/b

On Dec 5, 2008, at 10:11 AM, Apostolos Pantsiopoulos wrote:

[regs at kinetix.gr]

Both legs are SIP. From non-registered endpoints (if of any use).

Michael S Collins wrote:

[anthony.minessale at g...]

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 (brian@freeswitch.org)> wrote:

[regs at kinetix.gr]

FreeSWITCH Version 1.0.trunk (10579)

Brian West wrote:

[msc at freeswitch.org]

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:

[regs at kinetix.gr]

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:

[anthony.minessale at g...]

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

[regs at kinetix.gr]

Any updates about the "which side hanged up" potential variable?

Michael S Collins wrote:

[anthony.minessale at g...]

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:

[regs at kinetix.gr]

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:

[anthony.minessale at g...]

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:

[regs at kinetix.gr]

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