Cannot Receive Incoming Video Calls

[kmarie]

We have an 890 with two PRIs (Cox Commuincations) coming into our 890 breaking them out into BRIs for video teleconferencing. Up until recently we were able to make and receive video calls. Out of the blue we can no longer receive calls. I have checked our settings and verified with other commands I haven't see any descrepencies that I think would make a difference. The phone number match the IN#Accept (no more than 7 digits). As far as I know, no one has made any changes in our 890. Cox is telling us it's our equipment causing the problem, however the building across the street has the same problem.  When we have someone try to dial into us our 512 displays Bonding 1 Setup then there's a quick disconnect. Below is a snipet of what we see in the event log when a call tries to come in but I have no clue what I'm looking at.

M-5A Release_CMP

Prot:08     CRL:2     CRV:2

Ctl: Info     NS:42

Sent=Sapi:00     C/R: R     Tei:00

M-4D Release

Prot:08     CRl:2     CRV:1

Ctl: Info     NS:94

Sent=Sapi:00     C/R: R Tei:00

Any help would be greatly appreciated. Thank you.

[Anonymous]

The log you included is the "Release" and "Release_CMP" (release complete) messages. This is the call being disconnected.

In order to see the Release/release complete you obviously have the "ISDN L2 Formatted" messages set to INFO. Unless you suspect some type of messaging error, I don't believe you need that much detail. I suggest setting ISDN L2 FORMATTED to MINOR and set the "ISDN Events" to INFO. I also suggest having SWITCHBOARD set to INFO. I'm curious how many calls go through the ATLAS. Since you are BONDING in the 512, there should be at least 2 calls, but there should probably be a total of 6 calls through the ATLAS in order to reach 384 Kbps.

So with ISDN EVENTS set to INFO you should see 6 "CALL TO ATLAS" messages on the PRI interface, and then the BRI interfaces should show "DIALING" for each of those inbound calls. If all the calls come in on the PRI but do not go out the BRI then you'll have to verify the numbers configured in the ATLAS for the BRIs and that the SPIDs are all registered.

You can post the ISDN & Switchboard events when you collect them.

Thank you,

Patrick

[kmarie]

I've attached the event log. We made an outbound video 384k call and had a video 384k call try to come in. Is this log what you were referring to?

Message was edited by: kmarie

[Anonymous]

Yes, thank. This is what I wanted. (I think the labelling is backwards, though.)

On what I believe was the inbound call to 757-673-5507 (but looks to be labeled Outgoing Call), there is either issue with the SPIDs not being registered, or with the PHONE NUMBER under the SPID LIST. (Get the message "No
unbusy SPID matches the profile" on each of the ports that it cannot route the call to.)  The ATLAS receives the call to 757-673-5507 and starts with Slot 4 Port 1 and does not find an available port until it hits Slot 7 Port 5.

Since the "Call to ATLAS" is a 10-digit number (7576735507), the IN#ACCEPT should be all 10 digits with the PHONE# (under the SPID LIST) as only the last 7-digits (which you said you have). I suggest rebooting the ISU 512 and verifying all the SPIDs register, then verify the PHONE# on each BRI.

On the outbound call, the ISU 512 dials 2008367 and connects, then dials 2008477 and connects. Those are the only 2 channels dialed so no more channels can be established.

[kmarie]

We have the $ in the IN#Accept. I rechecked the numbers in the SPID List, we have 7 digits for the phone number and 10 digits plus the National ISDN code. I verified the SPIDs in the 512. I reset the 512 and saw the SPIDs register in the Event Log. We then had someone try to make an inbound video call into us and we saw the same information in the Event Log that I sent to you.

We did find out that the building across from us is experiencing the same issue and they have the same phone number prefix that we are having problems with. I just have to rule out that it is our equipment causing the problem before Cox will escalate or ticket.

Thanks for your help.

[Anonymous]

If the IN#ACCEPT is "$" then that explains the inbound call trying each of the BRI ports. I'm assuming Slot 7 Port 5 is the correct port to accept 7576735507.

Since I don't see any additional calls, either the Bonding Negotiation failed, or the dialing equipment dialed an invalid number, or the number that WAS dialed was routed incorrectly by the Telephone Company. You need to find out if the dialing equipment dials all 6 channels or not. The Bonding negotiation is done across the first channel that connects. The answering equipment tells the dialing equipment what numbers it needs to dial in order to connect the number of channels they negotiate. If the dialing equipment does dial all 6 channels, you need to find out what numbers it is dialing and if those numbers should come in the PRI. Does the ISU 512 STATUS buffer show any kind of error on the inbound call? (Such as TXINIT Expire, or some other bonding error?)

On the oubound call, only 2 numbers were dialed. That could possibly be a Bonding negotiation malfunction, where only 2 channels were negotiated.

[kmarie]

When we receive an incoming call it only connects one channel and then times out and disconnects, we never see the other channels trying to connect. The 512 typically will just say Bonding 1 Setup and sometimes Call Connect B1. We cannot receive incoming calls from anyone, we do not have any issues with outbound calls and that is the only way we are operating right now (making all calls). Telco keeps trying to tell me that it's our equipment and the way we are routing calls, I really do not believe this to be the case. I asked if they could see how far back this issue goes, they say they see a slow decline in incoming calls in Feb and then a major drop in the beginning of June. I know we did not change anything but they are saying the same thing. We are at a standstill waiting for Telco to get back with us. The building across the street has the same issue and have the same telephone number prefix.

[Anonymous]

Can the person calling into you verify if they are dialing more than one number? If they can, can they verify what numbers they are dialing? You can also have them try dialing each of the 6 numbers you have for your 384 Kbps video connection and see if all 6 numbers are routed to the ATLAS from the Telco. If they are not then the Telco needs to look at their call routing and find out why those numbers are not being routed.

The log shows only the first channel getting to the ATLAS and connecting. It could be the configuration in the ISU 512 having the dialing side dial the wrong numbers for the rest of the channels, but there is no way to tell in the ATLAS what happens with the Bonding negotiation.

If you can dial each of the 6 numbers for your video Codec, and not all of them reach the ATLAS, you can then give specific numbers to the telco and have them find out where those are being routed.

[Anonymous]

Since we haven't heard anything back from you, I'm going to mark this question as "assumed answered". If you have additional questions feel free to continue the discussion.

[kmarie]

Thanks to Patrick we figured out one of the issues we were having, our LDNs were wrong in the Adtran ISU 512. Once that was corrected we were able to receive incoming calls into that particular room. We don't know what was causing the issue in the other rooms or when it was fixed. We are assuming that resetting the PRIs cleared any issues because the command across the street was having the same issue. We checked their LDNs and their 550 settings and all was good. We reset their PRIs and we were able to accept incoming calls without making any changes anywhere. Thank you Patrick for all your time and help!