Jump to content

Dissconnected calls


russelln

Recommended Posts

B) Still fighting with CS410 and fxo ports, here is what the log shows...3 examples, it took about 8 calls on 2 lines to make this happen... these are the logs of the dissconnect. they are always the same..

 

this is trying to answer call with line button,

 

[5] 2008/02/25 20:54:44: PSTN: Tone Detection set to 65

 

[9] 2008/02/25 20:54:44: SIP Rx tls:192.168.1.102:2114:

SIP/2.0 200 Ok

Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK-39d8eeeaa7c77e35eb1825b28dba7128;rport=5061

From: <sip:41@localhost>;tag=1464018435

To: <sip:41@localhost>

Call-ID: 995ertnx@pbx

CSeq: 425522172 MESSAGE

Content-Length: 0

 

 

[5] 2008/02/25 20:54:44: PSTN: Received LoopInterrupt (remote hung up) signal on channel 1

 

[9] 2008/02/25 20:54:44: SIP Rx udp:127.0.0.1:5062:

BYE sip:3256723475@localhost;user=phone SIP/2.0

Via: SIP/2.0/UDP 127.0.0.1:5062

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=1875335928

To: <sip:3256723475@localhost;user=phone>;tag=3c89074652

Call-ID: 984b35ae@fxo

Contact: <sip:127.0.0.1:5062>

CSeq: 2 BYE

Content-Length: 0

 

As you can see the port sends the loopinterrupt signal..

 

Now we try answering a call with the speaker button..

 

[7] 2008/02/25 21:09:19: Call 6ad0cb7e@pbx#437402907: Clear last INVITE

[9] 2008/02/25 21:09:19: Resolve 2662: url sip:192.168.1.101:2103;transport=tls

[9] 2008/02/25 21:09:19: Resolve 2662: a tls 192.168.1.101 2103

[9] 2008/02/25 21:09:19: Resolve 2662: tls 192.168.1.101 2103

[9] 2008/02/25 21:09:19: SIP Tx tls:192.168.1.101:2103:

ACK sip:40@192.168.1.101:2048;transport=tls;line=ozvturjr SIP/2.0

Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK-8c28246161e6cca502a3fc3a4fd219b6;rport

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=437402907

To: <sip:3256725804@localhost;user=phone>;tag=lr795k5d1g

Call-ID: 6ad0cb7e@pbx

CSeq: 4653 ACK

Max-Forwards: 70

Contact: <sip:40@192.168.1.100:5061;transport=tls>

Content-Length: 0

 

 

[5] 2008/02/25 21:09:19: PSTN: Received LoopInterrupt (remote hung up) signal on channel 0

 

[9] 2008/02/25 21:09:19: SIP Rx udp:127.0.0.1:5062:

BYE sip:3256725804@localhost;user=phone SIP/2.0

Via: SIP/2.0/UDP 127.0.0.1:5062

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=1172755590

To: <sip:3256725804@localhost;user=phone>;tag=91edad2caa

Call-ID: 1baa52e0@fxo

Contact: <sip:127.0.0.1:5062>

CSeq: 2 BYE

Content-Length: 0

 

 

[9] 2008/02/25 21:09:19: Resolve 2663: aaaa udp 127.0.0.1 5062

[9] 2008/02/25 21:09:19: Resolve 2663: a udp 127.0.0.1 5062

[9] 2008/02/25 21:09:19: Resolve 2663: udp 127.0.0.1 5062

[9] 2008/02/25 21:09:19: SIP Tx udp:127.0.0.1:5062:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 127.0.0.1:5062

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=1172755590

 

As we see again, the loopinteruppt causes the hangup,

 

Now we try to answer with the handset..

5] 2008/02/25 21:13:00: PSTN: Channel 0 goes offhook

 

[3] 2008/02/25 21:13:00: PSTN: Channel 0 going to TALKING

 

[5] 2008/02/25 21:13:00: PSTN: Country Code set to 64

 

[5] 2008/02/25 21:13:00: PSTN: Tone Detection set to 64

 

[5] 2008/02/25 21:13:00: PSTN: Received LoopInterrupt (remote hung up) signal on channel 0

 

[9] 2008/02/25 21:13:00: SIP Rx udp:127.0.0.1:5062:

BYE sip:3256725804@localhost;user=phone SIP/2.0

Via: SIP/2.0/UDP 127.0.0.1:5062

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=654887343

To: <sip:3256725804@localhost;user=phone>;tag=1498108673

Call-ID: 204ef259@fxo

Contact: <sip:127.0.0.1:5062>

CSeq: 2 BYE

Content-Length: 0

 

 

[9] 2008/02/25 21:13:00: Resolve 2719: aaaa udp 127.0.0.1 5062

[9] 2008/02/25 21:13:00: Resolve 2719: a udp 127.0.0.1 5062

[9] 2008/02/25 21:13:00: Resolve 2719: udp 127.0.0.1 5062

[9] 2008/02/25 21:13:00: SIP Tx udp:127.0.0.1:5062:

 

Again the same thing causes the hangup, I left an expose of what I think is going on, but no one has responded to that post, on the dissconnected calls post,

I get calls through about 40 percent of the time on my phone lines with this thing,,,

 

I think it responds to the CPC pulse to quickly and can feel short variations of battey on the line, is there anyway to adjust the CPC repsonse time? on the FXO server side of the switch in the box? I think if it could be increased, it would quit dropping the calls, or does anyone know how long a CPC pulse it takes to dissconnect the calls in the box.? Or is it adjustable, or does it use something else?

 

any help would be appreciated... :blink:

Link to comment
Share on other sites

Ehh... FXO is not FXO... Maybe we really need to think about a couple of settings, like "check polarity change", "loop disconnect timeout time".

 

We are using this new Comcast service and I love it. No such problems, just great audio over a very short FXO cable.

 

Well today we put a meter on the line, I used a fluke that uses a bar graph, phone line shows about 54vdc not in use, 8vdc in use, about 87vac on the ringer, what was neat though, and I could only see it when I call out to another phone was that when the line was to ring the line to the called party, I could see the bar graph drop to nearly 0v before the call was connected, it is this little loss of line current or a zero voltage that i get refelected back from my phone co, that is being sensed by the appliance that causes the dissconect, its real fast, not even near 400ms, which is a pretty common cpc pulse time for most pbx's I have messed with, so does anyone know how to increase the pulse detect time on the box? :huh:

and does anyone know what the box uses as a dissconnect pulse time? :huh:

 

I sure would like to be able to use this thing...

 

thanks :unsure:

Link to comment
Share on other sites

I sure would like to be able to use this thing...

 

Welcome to the world of Pots Lines. The ole' timer Linemen will tell us horror stories about being on the poles, opening boxes with a million bugs and much more. Here we set in our offices at a keyboard...Get some tools and get a bit dirty and dig in.

 

Determining the quality of the lines and pressing the local telco to provide in spec lines is the next step,

 

http://www.sandman.com/files/teldiagchart.pdf

 

This might help get some detailed data on diagnosing line troubles.

Link to comment
Share on other sites

Welcome to the world of Pots Lines. The ole' timer Linemen will tell us horror stories about being on the poles, opening boxes with a million bugs and much more. Here we set in our offices at a keyboard...Get some tools and get a bit dirty and dig in.

 

Determining the quality of the lines and pressing the local telco to provide in spec lines is the next step,

 

http://www.sandman.com/files/teldiagchart.pdf

 

This might help get some detailed data on diagnosing line troubles.

 

hi,

 

thanks for the info, but according to your info, things look ok other than the off hook being a little hot, it is the little short open circiut that comes from placing the call that causes the dissconnect...that is what the log says, I sure wish someone at PBXNSIP would let me know what they use as a CPC dissconnect time in the box, and is there anyway to adjust it at all..I guess I can set up a pulse generator and measure it, but this should be information they know..if any slight loss of loop current can dissconnect this thing, then the wind blowing real hard can shut it down...I mean I do not intend to give up my POTS lines for any reason..I would like to have more lines on a sip trunk to dial out from and catch the additional calls that may come from time to time...

 

analog switches give you some options to deal with some of the inconsistantcies of lines, the box is a nice idea, but if the analog side of it can not be dealt with, then this is not going to be a viable thing in my part of the world, I live in a smaller area surround by rual communities, which the digital age has not reached or may never reach..and with the horror stories of VOIP phone companies crashing..and the hardware failing, then the ability to plug in an old phone has great value to me...

 

I was wanting to sell this technology...but I do not need the headaches that I have caused for my self...to be shared by my customers...

 

:unsure:

Link to comment
Share on other sites

I was wanting to sell this technology...but I do not need the headaches that I have caused for my self...to be shared by my customers...

 

10-4

 

I guess we should crack one open and locate the FXO chipset controller and download the SDK from the vendor to get these answers.

Link to comment
Share on other sites

10-4

 

I guess we should crack one open and locate the FXO chipset controller and download the SDK from the vendor to get these answers.

 

hmm....crack open box....

 

phone line interface..

http://datasheet.digchip.com/099/099-00751-0-CPC5620.pdf

 

phone line monitor...

http://www.clare.com/home/pdfs.nsf/www/cpc...le/cpc5710N.pdf

 

QUAD DIFFERENTIAL COMPARATORS...

http://focus.ti.com/lit/ds/symlink/lm239.pdf

 

4 channel controller convertor.....

http://www.legerity.com/getfile.php?bpd_27...F2_ID080753.pdf

does fig. 23a. and 23b. mean what I think it does??? :huh:

 

SDK...

http://www.legerity.com/products.php?sid=&bpid=68

 

waiting for password....

 

all the best.. :unsure:

Link to comment
Share on other sites

hmm....crack open box....

 

Cracked it open I see, but without detailed knowledge of the circuit design, you can't draw any conclusions from the diagrams. I think I know what you are thinking, but it probably doesn't really apply. (this is a debounce not a detection circuit)

 

So, for some reason the POTS line or lines that you are using have a brief period of (OPEN) causing calls to disconnect. Is this right?

Did you elaborate as to who is proving your POTS service? Have tried another POTS line? I ask as we have more than 1 of these CS410's deployed and we don't see this trouble. Does it behave this way regardless of which FXO port you are using? (How about more load onto the line like a answering machine.

Link to comment
Share on other sites

Cracked it open I see, but without detailed knowledge of the circuit design, you can't draw any conclusions from the diagrams. I think I know what you are thinking, but it probably doesn't really apply. (this is a debounce not a detection circuit)

 

 

So, for some reason the POTS line or lines that you are using have a brief period of (OPEN) causing calls to disconnect. Is this right?

It is either open or 0volts

 

Yes, has been verified by watching line voltages as calls are made and received, happens on both my incomming calls and out going calls, happens on both both of my lines, has been verified on fxo 1 and fxo 2,

 

the dissconnect happens when the line switches from dialing to ringing, if the call continues to ring, it will also happen between the time the call is going from ringing to connected on the analog line...sometimes it will connect the call, if you call a know busy number it will never connect to the busy signal..it just dissconnects

 

always get this message on the port that hangs up.

 

[5] 2008/02/25 21:13:00: PSTN: Received LoopInterrupt (remote hung up) signal on channel 0

(it would be nice to know what the the CPC time is for the box)

 

 

Did you elaborate as to who is proving your POTS service?

if you meant providing, it is AT&T

(guess i will try to find out what the wire is hooked up to on their end, I have friend that might be able to find out)

 

if you meant proving, I am the one making the measurments, I guess I can hook up the scope and watch it also, to get some idea of the time of the pulses being received, I used to have a one shot generator, sold it on ebay a few years ago, never used it except to screw up reception of television signals, it would have been perfect to figure out the cpc time on the box

 

Have tried another POTS line?

Just the 2 I have comming into my business, I guess I could drag it to the warehouse and try the line there..and the one at home..

 

I ask as we have more than 1 of these CS410's deployed and we don't see this trouble.

 

Does it behave this way regardless of which FXO port you are using?

Only have been using ports 1 and 2 but now have tested on 3 and 4, it happens on all, sometimes calls get through, sometimes they dont..

 

 

port 4 dissconnecting

6] 2008/03/03 20:58:59: PSTN: Start call on 3

 

[5] 2008/03/03 20:58:59: PSTN: Channel 3 goes offhook

 

[3] 2008/03/03 20:58:59: PSTN: Channel 3 going to TALKING

 

[5] 2008/03/03 20:58:59: PSTN: Country Code set to 67

 

[5] 2008/03/03 20:58:59: PSTN: Tone Detection set to 67

 

[5] 2008/03/03 20:58:59: PSTN: Received LoopInterrupt (remote hung up) signal on channel 3

 

Port 3 dissconnecting

5] 2008/03/03 21:05:22: PSTN: Channel 2 goes offhook

 

[3] 2008/03/03 21:05:22: PSTN: Channel 2 going to TALKING

 

[5] 2008/03/03 21:05:22: PSTN: Country Code set to 66

 

[5] 2008/03/03 21:05:22: PSTN: Tone Detection set to 66

 

[9] 2008/03/03 21:05:22: SIP Rx tls:192.168.1.101:2487:

SIP/2.0 200 OK

Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK-549762ed269ab686e9305428085ac8d9;rport=5061

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=877315384

To: <sip:CO3@localhost;user=phone>;tag=c47nused9r

Call-ID: 397c5fb9@pbx

CSeq: 5881 CANCEL

Content-Length: 0

 

 

[7] 2008/03/03 21:05:22: Call 397c5fb9@pbx#877315384: Clear last request

[9] 2008/03/03 21:05:22: SIP Rx tls:192.168.1.101:2487:

SIP/2.0 487 Request Terminated

Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK-549762ed269ab686e9305428085ac8d9;rport=5061

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=877315384

To: <sip:CO3@localhost;user=phone>;tag=c47nused9r

Call-ID: 397c5fb9@pbx

CSeq: 5881 INVITE

Contact: <sip:40@192.168.1.101:2048;transport=tls;line=ozvturjr>;flow-id=1

Content-Length: 0

 

 

[7] 2008/03/03 21:05:22: Call 397c5fb9@pbx#877315384: Clear last INVITE

[9] 2008/03/03 21:05:22: Resolve 80: url sip:192.168.1.101:2487;transport=tls

[9] 2008/03/03 21:05:22: Resolve 80: a tls 192.168.1.101 2487

[9] 2008/03/03 21:05:22: Resolve 80: tls 192.168.1.101 2487

[9] 2008/03/03 21:05:22: SIP Tx tls:192.168.1.101:2487:

ACK sip:40@192.168.1.101:2048;transport=tls;line=ozvturjr SIP/2.0

Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK-549762ed269ab686e9305428085ac8d9;rport

From: "Anonymous" <sip:anonymous@localhost;user=phone>;tag=877315384

To: <sip:CO3@localhost;user=phone>;tag=c47nused9r

Call-ID: 397c5fb9@pbx

CSeq: 5881 ACK

Max-Forwards: 70

Contact: <sip:40@192.168.1.100:5061;transport=tls>

Content-Length: 0

 

 

[5] 2008/03/03 21:05:22: PSTN: Received LoopInterrupt (remote hung up) signal on channel 2

 

[9] 2008/03/03 21:05:22: SIP Rx udp:127.0.0.1:5062:

 

 

(How about more load onto the line like a answering machine.

have used with telephones stilll hooked up on the lines, with one phone and 2 phones, and no phones..

 

time to go home... ;)

Link to comment
Share on other sites

I once had a problem with a line and the LEC was (sprint/embarq) I placed a call on a wierd problem and I finally spoke with a tech that was familiar with the switch (siemens) and was able to set an option on the associated lines and the problems were solved.

 

I'd place a trouble ticket, explain that calls are being dropped, and before you approve them dispatching ($$) you's like to talk to someone about the options on this lines. I'd take them elsewhere also and retry. (Hell the damn thing could be bad too)

Link to comment
Share on other sites

  • 2 weeks later...

Well finally got rigged up to measure record the pulses on the box, this first picture is of the box capturing the line, I see this pulse right as the dialing tones string are sent out, this pulse is always the same, and the box never dissconnects on this pulse..it lasts about 70ms, scope time was set to 50ms...

 

 

the next picture is the box dropping the line just called, it sometimes connects, so I guess this is where the margin is, on where the box deceides when to dissconnect, you can see the line going back to the connected call state, after the pulse, but then a decesion is made to dissconnect the line from the the voltage going to max again...you can see the pulse time is about 80ms and at about 120ms the call is dissconnected, these always look about the same.

 

 

now we call a busy line, I have never heard a busy signal, all pulses coming from a busy signal are always longer than when the line is not busy, this looks like it is about 110ms, but again you see the line recover and a decesion is made to dissconnect the call...75ms later.

 

 

Now I managed to get a call connected ( because it does connect about 50% of the time) and had the other party hang up, I held the line for the CO CPC pulse and here it comes about 30 seconds after and we see the pulse is about 850ms, it took two frames to show the time as it is much longer...than the little blips I get making calls, according to what i have seen ,it looks like the box makes the decesion around 60 ms or so to consider the call dissconnected, because 70ms is too long...

 

 

It seems like you could use the debounce function in the port controller chip to check for no current and then create a loop to count against the processor clock in the cpu, if there is no debounce at that time then the line is at off hook you would not send the loop interrupt to the 127 server, and you could make the count adjustable for different CPC times..would really be nice to be able to increase the CPC time...

 

all the best :huh:

 

russelln

Link to comment
Share on other sites

If you can try the update image at http://www.pbxnsip.com/protect/update-2894.tgz. But make a backup of your old config, maybe even of the whole file system.

 

This image has a new option for "CPC Duration" - try a higher value than 80 ms. Hopefully that helps sorting out this problem. You might also want to turn off Polarity Change detection and Busy tone detection.

Link to comment
Share on other sites

If you can try the update image at http://www.pbxnsip.com/protect/update-2894.tgz. But make a backup of your old config, maybe even of the whole file system.

 

This image has a new option for "CPC Duration" - try a higher value than 80 ms. Hopefully that helps sorting out this problem. You might also want to turn off Polarity Change detection and Busy tone detection.

set cpc to 400ms, left everything else the same..

 

I heard a busy signal, I can dial back in on my own lines, called in and out have not dropped a call yet..

 

thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,thankyou,

 

russell :):):D:D:D:D

Link to comment
Share on other sites

Somebody has way to much time on their hands. With 5 CS410's in play, and more coming on different carriers, I'm really hoping to see you get some relief.

 

No I really do not have the time, It is that I have a investment in this product and and I want to see it sucessful, also I wanted to fully make sure that I understood the problem as well as everybody else, because I might be wrong.(which I am alot)..the are of engineering is making sure everything is correct, I feel....better to have trouble now before I have 200 of these in the feild and wondering what the heck is going on when the phone co makes a little change that is still withing the specs of the analog system...thank you for your suggestions, because opening the box helped alot, (I started in this world as board level repair person, just did not think to look in the box),because when I knew the controller could detect a loop loss as little as 1ms, I figured it was a software issue with respect to programmer's logic towards how he understood the how the phone network behaves, the scope pictures showed me it was the box making the decesion, which I was not really sure of till that time..

 

all the best

 

russelln :)

Link to comment
Share on other sites

Grew Up doing board level repair on mainframes in the 70, mini's in the 80's all the while being a true hacker on IMSAI, OSI, and to many others to mention. I figured the controllers in the FXO gateway portion had to be stock stuff. You confirmed that and provided the necessary info for the folks to hit a home run. I wasn't completely sure though the firmware on on the controller was accessible. Likewise, I'm glad you stuck it out and provided the necessary info to get a resolution.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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.

×
×
  • Create New...