Happy Posted December 22, 2010 Report Share Posted December 22, 2010 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 22, 2010 Report Share Posted December 22, 2010 Does the hangup occur from a analog line? Do you see a BYE hitting the PBX? Quote Link to comment Share on other sites More sharing options...
Happy Posted December 24, 2010 Author Report Share Posted December 24, 2010 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. Quote Link to comment Share on other sites More sharing options...
Happy Posted December 27, 2010 Author Report Share Posted December 27, 2010 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 28, 2010 Report Share Posted December 28, 2010 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. Quote Link to comment Share on other sites More sharing options...
Happy Posted December 28, 2010 Author Report Share Posted December 28, 2010 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 ... Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 28, 2010 Report Share Posted December 28, 2010 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. Quote Link to comment Share on other sites More sharing options...
Happy Posted January 3, 2011 Author Report Share Posted January 3, 2011 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 3, 2011 Report Share Posted January 3, 2011 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 Quote Link to comment Share on other sites More sharing options...
Happy Posted January 4, 2011 Author Report Share Posted January 4, 2011 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 ? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 4, 2011 Report Share Posted January 4, 2011 How many messages are you logging? 500 already? Otherwise, just log to the file this will not purge messages Quote Link to comment Share on other sites More sharing options...
Happy Posted January 18, 2011 Author Report Share Posted January 18, 2011 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. Quote Link to comment Share on other sites More sharing options...
Happy Posted February 2, 2011 Author Report Share Posted February 2, 2011 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 Quote Link to comment Share on other sites More sharing options...
Happy Posted February 2, 2011 Author Report Share Posted February 2, 2011 Ok, no log file added. We'll give it a second try. Regards, Marc log0118.txt Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 2, 2011 Report Share Posted February 2, 2011 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. Quote Link to comment Share on other sites More sharing options...
Happy Posted February 4, 2011 Author Report Share Posted February 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2011 Report Share Posted February 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.