bskeddle Posted March 20, 2009 Report Share Posted March 20, 2009 The CS410 is connected to a Time Warner SBV5322 that provides 3 “pots” lines connected to FXO1 – FXO3. (the 4th line runs directly to a fax.) CS410 Version 3.3.0.3160 X-Lite soft phones 3.0 build 47546. The system worked perfectly for 6 months. 1) For the last week we have been "receiving" calls from Anonymous (anonymous@localhost) [PSTN] after any call has been ended (from either side). a. None of the FXOx port indicators are lit, but the system does list the “call” on the “Currently Active Calls” page. b. The line is silent when answered and when unanswered the Ghost calls connect to VM boxes and fill them with blank messages. c. An email with a RE line similar to:"CS410: RTP Timeout on 81304908@fxo#d1caa153cb" is sent stating that "The call between sip:7608328620@localhost;user=phone and sip:anonymous@localhost;user=phone has been disconnected because of media timeout (120 seconds), 0/5994 packets have been received/sent" 2) For the last month FXOx ports will randomly “lock up” making that line unavailable. a. The FXOx port indicator will light, but the system does not indicate a call in the “Currently Active Calls” page. b. If two internal users are on lines, when the third user dials out the system will drop one of the existing calls. c. Sometimes unplugging the line from the offending FXO port will clear the problem, other times the CS410 will have to be restarted. We purchased our CS410 directly from PBXnSIP (and therefore do not have a reseller to turn to for support). Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 20, 2009 Report Share Posted March 20, 2009 The CS410 is connected to a Time Warner SBV5322 that provides 3 "pots" lines connected to FXO1 – FXO3. (the 4th line runs directly to a fax.)CS410 Version 3.3.0.3160 X-Lite soft phones 3.0 build 47546. The system worked perfectly for 6 months. That of course raises the question: Has anything changed in the setup? 1) For the last week we have been "receiving" calls from Anonymous (anonymous@localhost) [PSTN] after any call has been ended (from either side). a. None of the FXOx port indicators are lit, but the system does list the "call" on the "Currently Active Calls" page. b. The line is silent when answered and when unanswered the Ghost calls connect to VM boxes and fill them with blank messages. c. An email with a RE line similar to:"CS410: RTP Timeout on 81304908@fxo#d1caa153cb" is sent stating that "The call between sip:7608328620@localhost;user=phone and sip:anonymous@localhost;user=phone has been disconnected because of media timeout (120 seconds), 0/5994 packets have been received/sent" 2) For the last month FXOx ports will randomly "lock up" making that line unavailable. a. The FXOx port indicator will light, but the system does not indicate a call in the "Currently Active Calls" page. b. If two internal users are on lines, when the third user dials out the system will drop one of the existing calls. c. Sometimes unplugging the line from the offending FXO port will clear the problem, other times the CS410 will have to be restarted. It sounds a little bit like the PBX has problems with the FXO. Maybe it was on the edge already and now it is over the edge. Is the signal quality okay on the FXO (I don't know the Time Warner - is it connected through a short cable?). Maybe you can attache a screenshot of the settings for the FXO gateway on the CS410. It could be there is a parameter wrong. Quote Link to comment Share on other sites More sharing options...
bskeddle Posted March 23, 2009 Author Report Share Posted March 23, 2009 Thanks for getting back to me! "That of course raises the question: Has anything changed in the setup?" Nothing has changed on our side, and TimeWarner claims nothing has changed on their side. "It sounds a little bit like the PBX has problems with the FXO. Maybe it was on the edge already and now it is over the edge. Is the signal quality okay on the FXO (I don't know the Time Warner - is it connected through a short cable?). " TimeWarner is a cable co. they offer phone service though a Motorola cable modem (voip->pots). The pots cable from the modem is about 1 foot long. "Maybe you can attache a screenshot of the settings for the FXO gateway on the CS410. It could be there is a parameter wrong." OK.. here it is... Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 23, 2009 Report Share Posted March 23, 2009 The pots cable from the modem is about 1 foot long. I think we can rule out gain and noise problems... Can you log into the box and try the following? cd /etc/init.d vi pbxnsip then edit the line that starts the PSTN gateway: $SIPFXO --config /etc/sipfxo.conf --show-version /etc/sipfxo-rel ease --pbx-adr 127.0.0.1 --sip-adr 127.0.0.1 --csp-mac "$MAC0" --msp-mac "$MAC 1" >/dev/null 2>/dev/null & Add the option "--ignore-no-loop" to the options. That should disable the loop interrupt detection. Lets see if that shuts the loop interrups down. Quote Link to comment Share on other sites More sharing options...
bskeddle Posted March 23, 2009 Author Report Share Posted March 23, 2009 I think we can rule out gain and noise problems... I would try to increase the CPC time to something like 1000 (ms). Maybe that helps to reduce the problem and get from the "edge". According to my research, CPC Duration (or Loop Interruption) is the length of time that the phone co. interrupts the line voltage in order to signal the end of a call. If the CPC Duration is set longer than the actual length of the CPC "issued" by the phone co. the PBXnSIP will not interpret the voltage interruption as a CPC and therefore never disconnect. i.e. If I set it to 1000ms, the system will only disconnect after the line has 0 voltage for Greater than 1000ms. If the actual CPC Duration is only 600ms the PBXnSIP will not recognize it as a CPC and therefore not disconnect.. However if the CPC Duration is set to 400ms and the actual CPC is 600ms then the PBXnSIP will interpret any voltage interruptions Greater than 400ms (including real 600ms CPC's) as a CPC and will therefore disconnect. It seems that the purpose of setting a longer CPC Duration is to prevent unintended disconnects caused by random voltage interruptions. As the problem appears to be that the PBXnSIP is NOT disconnecting, how would setting the CPC higher help? Your help is very appreciated, as this phone stuff is new territory to me! Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 23, 2009 Report Share Posted March 23, 2009 According to my research, CPC Duration (or Loop Interruption) is the length of time that the phone co. interrupts the line voltage in order to signal the end of a call. If the CPC Duration is set longer than the actual length of the CPC "issued" by the phone co. the PBXnSIP will not interpret the voltage interruption as a CPC and therefore never disconnect. i.e. If I set it to 1000ms, the system will only disconnect after the line has 0 voltage for Greater than 1000ms. If the actual CPC Duration is only 600ms the PBXnSIP will not recognize it as a CPC and therefore not disconnect.. However if the CPC Duration is set to 400ms and the actual CPC is 600ms then the PBXnSIP will interpret any voltage interruptions Greater than 400ms (including real 600ms CPC's) as a CPC and will therefore disconnect. It seems that the purpose of setting a longer CPC Duration is to prevent unintended disconnects caused by random voltage interruptions. As the problem appears to be that the PBXnSIP is NOT disconnecting, how would setting the CPC higher help? Your help is very appreciated, as this phone stuff is new territory to me! Did you try the lower values? I have seen value of 80 working some of the installations. Quote Link to comment Share on other sites More sharing options...
bskeddle Posted March 24, 2009 Author Report Share Posted March 24, 2009 Did you try the lower values? I have seen value of 80 working some of the installations. I have tried 400 down to 1 (and upto 1500). No joy. According to my research "Detect Polarity Change" is a holdover from the days that batteries were used by the phone co. (they would reverse polarity to signal disconnect) and is no longer used in the USA. What does "FX Impedance" do? I think this point in the log is where the call (620e2245@pbx) is terminated by the user and the system creates the "ghost" call (6931fac9@fxo) back: [7] 2009/03/23 19:23:22: Call 620e2245@pbx#1847375296: Clear last request [5] 2009/03/23 19:23:22: BYE Response: Terminate 620e2245@pbx [3] 2009/03/23 19:23:22: PSTN: Channel 0: Hangup [5] 2009/03/23 19:23:22: PSTN: Channel 0 goes onhook [5] 2009/03/23 19:23:22: PSTN: enable_callerid 0 [3] 2009/03/23 19:23:22: PSTN: Channel 0 going to GO_ONHOOK [3] 2009/03/23 19:23:23: PSTN: Channel 0 going to IDLE [5] 2009/03/23 19:23:24: PSTN: eVAPI_CALLER_ID_DETECTED_EVENT [7] 2009/03/23 19:23:24: SIP Rx udp:127.0.0.1:5062: INVITE sip:760xxx8620@localhost;user=phone SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5062 From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=1804289383 To: <sip:760xxx8620@localhost;user=phone> Call-ID: 6931fac9@fxo Contact: <sip:127.0.0.1:5062;line=1> CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 137 What does the line: [5] 2009/03/23 19:23:24: PSTN: eVAPI_CALLER_ID_DETECTED_EVENT indicate is happening? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 24, 2009 Report Share Posted March 24, 2009 What does the line: [5] 2009/03/23 19:23:24: PSTN: eVAPI_CALLER_ID_DETECTED_EVENT indicate is happening? Well, that says that the PBX received a caller-ID (either through DTMF or FSK). Hmm. Do you mean that the disconnect is actually okay, but the detection of the caller-ID is the problem? Maybe the carrier wants to send some information after the call was disconnected? Quote Link to comment Share on other sites More sharing options...
bskeddle Posted March 24, 2009 Author Report Share Posted March 24, 2009 Well, that says that the PBX received a caller-ID (either through DTMF or FSK). Hmm. Do you mean that the disconnect is actually okay, but the detection of the caller-ID is the problem? Maybe the carrier wants to send some information after the call was disconnected? I DO NOT know!!! but Time Warner did a call trap for me and sent me this info: After carefully reviewing the call trap I have come to this conclusion. This call was terminated by the NON-TWC customer. Date/Time: 3/24/09 10:32 AM Originating TN: 760xxx8621 Terminating TN: 8588057174 Start with the RTP, which is the voice audio. The BYE response in BLUE is the off-net caller which was me hanging up. 481.600 seconds into the call. The 200 OK response in BLUE back from the soft switch to the Signaling Interface at 481.603 seconds into the call. The DLCX response in PURPULE from the soft switch to the MTA came at 481.604 seconds into the call. The 250 response in PURPULE from the MTA to the soft switch came at 481.692 seconds into the call. This was followed immediately by a NTFY on-hook from the MTA to the soft switch at 489.678 seconds into the call. This gave us a delay of 8 to 9 seconds from the DLCX to the on-hook response back to the soft switch. I have been advised by our Voice Analyst that this is normal and there should be delay of no more than 10 seconds. They stated that the was setup for 911 situations where if someone was calling the call would not immediately hang up by pressing the hook. I hope this information clarifies the situation. Please let me know if there is anything else that I can do to assist. Agilent NgN Monitor and Analysis Call Trace: Call Sequence: Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 25, 2009 Report Share Posted March 25, 2009 I DO NOT know!!! but Time Warner did a call trap for me and sent me this info: We made a test version that disables the detection of the caller-ID when the line is not in the ringing state. Can you give that version a try? After upgrading and testing, you can downgrade back to the version that you are running right now if the situation should not improve. http://pbxnsip.com/cs410/update-3.3.1.3170-ghost.tgz Quote Link to comment Share on other sites More sharing options...
bskeddle Posted March 25, 2009 Author Report Share Posted March 25, 2009 We made a test version that disables the detection of the caller-ID when the line is not in the ringing state. Can you give that version a try? After upgrading and testing, you can downgrade back to the version that you are running right now if the situation should not improve. http://pbxnsip.com/cs410/update-3.3.1.3170-ghost.tgz Testing it now. Looks like it will work! Will Report results tommorow. Quote Link to comment Share on other sites More sharing options...
bskeddle Posted March 27, 2009 Author Report Share Posted March 27, 2009 We made a test version that disables the detection of the caller-ID when the line is not in the ringing state. Can you give that version a try? After upgrading and testing, you can downgrade back to the version that you are running right now if the situation should not improve. http://pbxnsip.com/cs410/update-3.3.1.3170-ghost.tgz This solved the problem. Thank You! Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 27, 2009 Report Share Posted March 27, 2009 This solved the problem. Thank You! Great! The next 3.3.1 version will have it in the GA build. Quote Link to comment Share on other sites More sharing options...
Bill H Posted September 2, 2009 Report Share Posted September 2, 2009 Great! The next 3.3.1 version will have it in the GA build. We have a customer using a Cable Modem with a built-in FXS gateway. It looks like he is having the same trouble. CS_410 Version 3.3.2.3181 (Linux) Does this version include the Phantom Caller-ID fix????? 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.