IP500 SCN 5.0.15 and some weird SSA

[qtelcom]

I have 2 IP500's on 5.0.15 in an SCN. One IP500 has all IP phones 5610's. SCN calls will ring an extension, but the user cannot pick up a SCN IP trunk call at certain times, even if they hit their ringing a= button. btw the ringing a= button even shows the caller id, it is just that the user cannot answer. The phone works fine but it's like no audio path can be established, but signaling works fine, they also cannot go off hook to grab dialtone. The phone does not reboot, or goto discover mode and does not loose it's registration on the IP500. Rebooting the phone does not fix the problem. All phones are set to G.729, all SCN trunks are set to G.729. Direct Media path is turned off on all IP phones and SCN trunks. The problem is intermittent, as 5 minutes later SCN trunk calls are working again.

I have experienced some weird SSA issues, which is why I'm posting here. Upon looking at my IP extension list, I'll have a phone model show up as a 4624, no 4624 exists on the system, nor do they even own a 4624. and I can even reboot the phone and it'll come back as a 5610 correctly in SSA. Is this an SSA issue misreporting? or an IP Office issue?

Also when clicking on licenses in SSA, I'll have some of my licenses missing, namely my CCR licenses and the VCM licenses will show 0 available and 0 in use. When I open a config through Manager, all licenses are there and show valid, it's just SSA that will sometimes show them missing. When I click to a different part of SSA and then back to Licenses, (basically refreshing the display) they will sometimes all show back up correctly. Again, is this a SSA issue? or an IP office issue? Is it possible the VCM licenses are disappearing and reappearing on the unit in a span of a few seconds? or is that complete rubbish?

This has only happened on the one IP500. On the other IP500 unit, I have never had SSA show anything incorrectly in regards to VCM licenses or phone model type.

Anyone else seen this in SSA? I will be replacing the IP500 unit in question and all associated cards, maybe the LAN port is buggered or corrupting data somehow, or the VCM64 card is bad.

I've avoided updating to 5.0.18 because I don't trust that firmware level yet with IP phones and a SCN.

 

[amriddle01]

The first issue sound like ports being blocked (yes even intermittently), call setup and the streaming audio use completely different protocols and ports I would look at that side of things, Wireshark and Monitor will be your friends there. SSA is very buggy and always has been, often my IP and Dig phones show as "POTS CLI ON" no rhyme or reason, I have however never seen it miss out licences but I have seen many other odd things that all turn out to be red herrings, so as long as the liceneced programmes run ignore it

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

 

[merlinczar]

With the audio and control of the IP phones I have seen it where off site remote users softphones when audio was one way they could be heard but not speak and loss of control intermitten just quirky.
The issue happen to be dual trunk ports with load balancing between data switches. The customer removed one of the trunk ports tadaa the quirky behaviuor disappeared

 

[qtelcom]

Yeah, they are not doing any load balancing. They have multiple WAN ports with bonded T's and some other connections. Everything is handled by a pretty robust sonicwall, all traffic is VPN'd with sonicwalls to remote IP phones, no ports are blocked, everything is open. The sonicwall is reserving bandwidth for the IP phones just in case they happen to max out a connection. Network latency, jitter, & packetloss are within specs. Anything to do with H.323 transformations and such language on the sonicwalls have been disabled.

They will run for 3-4 days just fine, and then the problem starts. A manual reboot of the IP Office 500 seems to fix the problem. Setting up Wireshark now to see what's going on.

The remote IP phones use the SCN trunks a lot, so they end up RTP relaying to the second IP500 on the SCN trunk. If I were to set my SCN trunk on my 2 IP500's, to G711, and leave all the IP phones at G.729, would that force a SCN trunk call to use a VCM on each IP500? Right now, only one VCM resource is used for an SCN trunk call via RTP relay since all my codecs match. I know this would be in-efficient, but I may want to try this.

 

[merlinczar]

ok try this I think this might do it experiment. Under "extensions" disable (untick) "Allow direct media path". This may want want a reboot just make it merge. If you just reregister or login logout hot desk the phone this is usually all the reset you will need.
What this will do is keeps the packets and control at the phone system. If that does fix it (IT salute) it is a highly probable networking problem.
The "direct media path" allows cut thru point to point or phone to phone bypassing the phone system utilizing only switches and routers.
Have alot of fun!

 

[qtelcom]

check post, DMP is already unticked on all IP extensions and IP trunks.