You can experience at least the following hangup causes from FreeSWITCH itself: *ALLOTTED_TIMEOUT* - when you end the call by timer *MEDIA_TIMEOUT* - when there is no RTP for some period (I would assume it can happen if server lost network connection for some time) *ATTENDED_TRANSFER* - not sure when it will happen, but I saw this in CDR for an answered call Case with media timeout is a very special one. In this case user might have talked only for 60 seconds, but timeout happened after 1800 seconds (or how is configured). You have no way to know how much time exactly the clients have talked, because in the CDR you will see 1800 seconds. In this case I think it will be fair to bill just for 1 minute or so and accept your expenses. I never saw other hangup cases for answered calls from FreeSWITCH itself. Regards, Vitalie 2012/9/5 Steven Ayre <steveayre@gmail.com>

Do you have SIP traces for the call? If you're bridging then it's possible for the remote end to hangup the answered call with an ISDN clearing cause other than NORMAL_* (just like they can in ISDN signalling). For billing purposes I suggest you bill anything where billsec>0 rather than only NORMAL_CLEARING calls.

-Steve

On 4 September 2012 19:23, Muhammad Naseer Bhatti <nbhatti@gmail.com> wrote:

...

Hi, I am seeing a lot of calls with hangup cause/Enumeration is not NORMAL_CLEARING while the calls still have a valid duration and answered time. For a typical billing scenario, calls are billed if (answered time) billsec>0 and hangup cause = NORMAL_CLEARING. In what cases the enumeration would be other than normal and while the calls would be still a valid answered call?

Thanks

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

Do you have call failover when you bridge? It could be causes from the 1st gateway that failed, but your call continued to complete on the next one. Sent from my iPad On Sep 5, 2012, at 6:47 PM, Muhammad Naseer Bhatti <nbhatti@gmail.com> wrote: I don't have the SIP traces right now, but I see causes like MEDIA_TIMEOUT, *DESTINATION_OUT_OF_ORDER* , *NORMAL_UNSPECIFIED* , *NETWORK_OUT_OF_ORDER* and *RECOVERY_ON_TIMER_EXPIRE* and the calls were still good. We are not talking about a few, they were around 50K + calls for such reasons in 24 hours. I'll try to capture SIP for any new calls. Was just curious what's going on. -B On Wed, Sep 5, 2012 at 6:51 PM, Vitalie Colosov <vetali100@gmail.com> wrote:

You can experience at least the following hangup causes from FreeSWITCH itself: *ALLOTTED_TIMEOUT* - when you end the call by timer *MEDIA_TIMEOUT* - when there is no RTP for some period (I would assume it can happen if server lost network connection for some time) *ATTENDED_TRANSFER* - not sure when it will happen, but I saw this in CDR for an answered call

Case with media timeout is a very special one. In this case user might have talked only for 60 seconds, but timeout happened after 1800 seconds (or how is configured). You have no way to know how much time exactly the clients have talked, because in the CDR you will see 1800 seconds. In this case I think it will be fair to bill just for 1 minute or so and accept your expenses.

I never saw other hangup cases for answered calls from FreeSWITCH itself.

Regards, Vitalie

2012/9/5 Steven Ayre <steveayre@gmail.com>

...

Do you have SIP traces for the call? If you're bridging then it's possible for the remote end to hangup the answered call with an ISDN clearing cause other than NORMAL_* (just like they can in ISDN signalling). For billing purposes I suggest you bill anything where billsec>0 rather than only NORMAL_CLEARING calls.

-Steve

On 4 September 2012 19:23, Muhammad Naseer Bhatti <nbhatti@gmail.com> wrote:

...

Hi, I am seeing a lot of calls with hangup cause/Enumeration is not NORMAL_CLEARING while the calls still have a valid duration and answered time. For a typical billing scenario, calls are billed if (answered time) billsec>0 and hangup cause = NORMAL_CLEARING. In what cases the enumeration would be other than normal and while the calls would be still a valid answered call?

Thanks

_________________________________________________________________________

...

Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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

if continue_on_fail is false, I don't think it will be rolling over to additional gateways. On Sep 5, 2012, at 10:03 PM, Muhammad Naseer Bhatti <nbhatti@gmail.com> wrote:

We do bridge multiple gateways and capture failed gateways but the hangup cause shouldn't be the from the last tried gateway? That last gateway should have a good call because continue_on_fail = false. If the call fails 1st gw, the hangup cause in the cdr should come from the last tried gw rather than the 1st one.

-B

On Thu, Sep 6, 2012 at 4:51 AM, Dorn DJBinter <djbinter@gmail.com> wrote: Do you have call failover when you bridge? It could be causes from the 1st gateway that failed, but your call continued to complete on the next one.

Sent from my iPad

On Sep 5, 2012, at 6:47 PM, Muhammad Naseer Bhatti <nbhatti@gmail.com> wrote:

...

I don't have the SIP traces right now, but I see causes like MEDIA_TIMEOUT, DESTINATION_OUT_OF_ORDER , NORMAL_UNSPECIFIED , NETWORK_OUT_OF_ORDER and RECOVERY_ON_TIMER_EXPIRE and the calls were still good. We are not talking about a few, they were around 50K + calls for such reasons in 24 hours. I'll try to capture SIP for any new calls. Was just curious what's going on.

-B

On Wed, Sep 5, 2012 at 6:51 PM, Vitalie Colosov <vetali100@gmail.com> wrote: You can experience at least the following hangup causes from FreeSWITCH itself: ALLOTTED_TIMEOUT - when you end the call by timer MEDIA_TIMEOUT - when there is no RTP for some period (I would assume it can happen if server lost network connection for some time) ATTENDED_TRANSFER - not sure when it will happen, but I saw this in CDR for an answered call

Case with media timeout is a very special one. In this case user might have talked only for 60 seconds, but timeout happened after 1800 seconds (or how is configured). You have no way to know how much time exactly the clients have talked, because in the CDR you will see 1800 seconds. In this case I think it will be fair to bill just for 1 minute or so and accept your expenses.

I never saw other hangup cases for answered calls from FreeSWITCH itself.

Regards, Vitalie

2012/9/5 Steven Ayre <steveayre@gmail.com> Do you have SIP traces for the call? If you're bridging then it's possible for the remote end to hangup the answered call with an ISDN clearing cause other than NORMAL_* (just like they can in ISDN signalling). For billing purposes I suggest you bill anything where billsec>0 rather than only NORMAL_CLEARING calls.

-Steve

On 4 September 2012 19:23, Muhammad Naseer Bhatti <nbhatti@gmail.com> wrote:

...

Hi, I am seeing a lot of calls with hangup cause/Enumeration is not NORMAL_CLEARING while the calls still have a valid duration and answered time. For a typical billing scenario, calls are billed if (answered time) billsec>0 and hangup cause = NORMAL_CLEARING. In what cases the enumeration would be other than normal and while the calls would be still a valid answered call?