Jump to content
Vodia PBX forum
Happy

Detecting early hangup

Recommended Posts

Situation:

Ivr directly answering the phone, if user is pressing <1> or just remains on the line, HG connects call to extensions or to external line.

Ivr Dtmf List : !1!95! !E!95! ![^1]!-!

 

Problem:

When user hangs up the phone while the Ivr is playing, very often the 'empty' call is put through, as well to the extensions as to external line.

 

Is there a way to avoid this behaviour, because is is very annoying to get the empty calls.

We don't want to change the dtmf list so that user is only connected when he makes the right choice.

Share this post


Link to post
Share on other sites

Does the hangup occur from a analog line? Do you see a BYE hitting the PBX?

Hangup occurs from any line, analog, isdn or cellphone.

 

Don't know about the BYE. I have to log a test for that. I'll check it out.

Share this post


Link to post
Share on other sites

Does the hangup occur from a analog line? Do you see a BYE hitting the PBX?

I'm adding a logfile to this post.

The anonymus call came from a cellphone. Connection was terminated while the Ivr-Message was still playing.

Call got through anyway. I took the (empty) call on extension Bureel.

Log IVR Empty Call.txt

Share this post


Link to post
Share on other sites

It is a little bit hard to say what exactly was going on, but what I can see is that the gateway sent a BYE to the PBX (search for Call-ID 417e9feaab32afab). I cannot see the other messages in this call, but it could be the problem that for whatever reason the gateway wants the call to disconnect.

Share this post


Link to post
Share on other sites

what I can see is that the gateway sent a BYE to the PBX

All incoming calls come from a Patton Gateway BRI. Seems correct to me that the Gateway sends a BYE to the PBX when someone hang up the line.

 

but it could be the problem that for whatever reason the gateway wants the call to disconnect.

This needs some explanation, it looks logic to me that pbxnsip ends the call after a BYE from the gateway for whatever reason there might be. But it isn't happening ...

 

I cannot see the other messages in this call

Can I provide you with a better logfile to get a better understanding of what is going on. What log settings do you suggest ?

It would be a great relief to get this thing fixed ...

Share this post


Link to post
Share on other sites

Can I provide you with a better logfile to get a better understanding of what is going on. What log settings do you suggest ?

It would be a great relief to get this thing fixed ...

 

Just make the log history longer (or write the log into a file), so that you can see the initial INVITE that has the same Call-ID as the BYE from the gateway. Then we can see all messages that are exchanged between the gateway and the PBX.

Share this post


Link to post
Share on other sites

Just make the log history longer (or write the log into a file), so that you can see the initial INVITE that has the same Call-ID as the BYE from the gateway. Then we can see all messages that are exchanged between the gateway and the PBX.

The whole thing in attachment

Log Ivr Empty Call Full.txt

Share this post


Link to post
Share on other sites

Still the log starts with the ACK but not the INVITE:

 

[0] 2011/01/03 08:44:58: SIP Rx udp:192.168.1.2:5060:

ACK sip:patton@192.168.1.15:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKc5be534e8ef8eee06

Max-Forwards: 70

From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83

To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78

Call-ID: dd8a0982e3e2df15

CSeq: 1065 ACK

User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26

Content-Length: 0

 

Then the PBX receives the BYE:

 

[0] 2011/01/03 08:45:44: SIP Rx udp:192.168.1.2:5060:

BYE sip:patton@192.168.1.15:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK283d7c36279b55e3d

Max-Forwards: 70

From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83

To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78

Call-ID: dd8a0982e3e2df15

CSeq: 1066 BYE

User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26

Content-Length: 0

 

 

 

Share this post


Link to post
Share on other sites

Still the log starts with the ACK but not the INVITE:

 

[0] 2011/01/03 08:44:58: SIP Rx udp:192.168.1.2:5060:

ACK sip:patton@192.168.1.15:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKc5be534e8ef8eee06

Max-Forwards: 70

From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83

To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78

Call-ID: dd8a0982e3e2df15

CSeq: 1065 ACK

User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26

Content-Length: 0

 

Then the PBX receives the BYE:

 

[0] 2011/01/03 08:45:44: SIP Rx udp:192.168.1.2:5060:

BYE sip:patton@192.168.1.15:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK283d7c36279b55e3d

Max-Forwards: 70

From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83

To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78

Call-ID: dd8a0982e3e2df15

CSeq: 1066 BYE

User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26

Content-Length: 0

 

I can't pick up the INVITE.

Log settings : general logging sip events at log level 0/ log all sip events.

 

Is it something in the log settings ?

Share this post


Link to post
Share on other sites

How many messages are you logging? 500 already? Otherwise, just log to the file this will not purge messages

In addendum log-file, I did log to a file directly, so nothing will be purged.

Share this post


Link to post
Share on other sites

In addendum log-file, I did log to a file directly, so nothing will be purged.

Ok, no log file added.

We'll give it a second try.

 

Regards,

Marc

Share this post


Link to post
Share on other sites

One think that strikes out is the number "011-33333". In SIP the "-" is a part of the URI, in other words "011-33333" is not equal to "01133333". That might cause a lot of confusion.

 

The PBX likes to display numbers with "-" in it, but only for display purposes! Internally, the processing goes on without the "-". But when the number comes from a non-human device like the PSTN gateway, then the PBX will take it literally.

Share this post


Link to post
Share on other sites

One think that strikes out is the number "011-33333". In SIP the "-" is a part of the URI, in other words "011-33333" is not equal to "01133333". That might cause a lot of confusion.

 

The PBX likes to display numbers with "-" in it, but only for display purposes! Internally, the processing goes on without the "-". But when the number comes from a non-human device like the PSTN gateway, then the PBX will take it literally.

Hi,

 

I did a replace on the phone numbers, the '-' is there because of that. All phone numbers are in the original logfile in a complete numerical format. I am sorry for the confusion here.

 

The situation now is that the IVR connects directly to the HG for transferring the call. It seems to me that - for as long as you are in the IVR - pbxnsip does not detect a hangup. Would it be better to put in an extra IVR with a small message ? Probably Pbxnsip checks the status of the line in between the 2 IVR nodes?

 

Marc.

Share this post


Link to post
Share on other sites

The situation now is that the IVR connects directly to the HG for transferring the call. It seems to me that - for as long as you are in the IVR - pbxnsip does not detect a hangup. Would it be better to put in an extra IVR with a small message ? Probably Pbxnsip checks the status of the line in between the 2 IVR nodes?

 

The PBX does not perform special checks of the status between calls.

 

The PBX ignored hangup in the hunt group if the hangup comes from an unconnected device from the agent side. This is like the agent pressing the cancel button on an incoming call, the hunt group continues searching other agents that can connect the call. The hunt group also ignores redirection requests from agents (3xx codes). In other words, unless the call is connected the agent cannot cancel or redirect the call.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...