VPN Phones (again)

[wpetilli]

VPN phones deployed.. main call servers recently virtualized with new IP's.. all office phones register to new PE fine and VPN phones register for a few seconds and then go into discover. Phones get statically assigned and pointed to a web server housing the 46xx file. Tried manually changing the call server IP to a CLAN and that's not working either.

 

[wpetilli]

So this issue is still happening and we've been re-provisioning the phones with just CLAN IP's, which seemed to have worked. Not ideal, but worked nonetheless. Now, if that logged in vpn phone extension gets taken over back in the office there's no issue. If the VPN phone tries to take it back the same issue occurs.. scrolls through discovery and never registers. Network wise this looks all fine and I'm at a point where nothing is standing out as the common denominator other than the VE call servers. But again, 99% of the phones are registered to the PE fine and it's only these vpn phones. Can the interchanges, and ESS failovers have fluxed everything?

 

[kyle555]

Antyhing's possible. i've never really heard of procr interchanges causing network issues. SBCs - yes!, procr, not so much.

I'd say syslog the phone on debug level and PCAP from the VPN inward and the CM if possible.

 

[wpetilli]

User can only register an extension if it's logged out elsewhere. No longer able to take over extensions back and forth. Confirming if this is on normal/in office phones or only when a vpn phone is involved. Tried putting those in a different network region with the near end establishes tcp socket set to 'n'.. nothing works. Didn't want to start bouncing CP's and the PE.

 

[wpetilli]

When I go into the event logs on the server I see a ton of these msg's.



20170712:000910500:2376308:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=8c30 d2=10.140.217.12]
20170712:000913478:2376315:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c30 d2=10.140.217.12]
20170712:000916477:2376325:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c30 d2=10.140.217.12]
20170712:000917782:2376330:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=8c4c d2=10.140.217.19]
20170712:000918977:2376336:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=9f73 d2=10.140.217.144]
20170712:000919832:2376342:capro(25702):MED:[ denial event=1962 IP LRJ-No H323 sig group d1=0000 d2=10.2.130.203]
20170712:000920051:2376345:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=8c30 d2=10.140.217.12]
20170712:000920792:2376351:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c4c d2=10.140.217.19]
20170712:000921960:2376359:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=9f73 d2=10.140.217.144]
20170712:000922916:2376362:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=9f92 d2=10.192.60.57]
20170712:000922922:2376364:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=8c16 d2=10.140.217.222]
20170712:000923037:2376368:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c30 d2=10.140.217.12]
20170712:000923803:2376376:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c4c d2=10.140.217.19]
20170712:000924960:2376381:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=9f73 d2=10.140.217.144]
20170712:000925905:2376385:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c16 d2=10.140.217.222]
20170712:000926037:2376389:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c30 d2=10.140.217.12]
20170712:000926720:2376391:capro(25702):MED:[ denial event=1934 IP RRJ-Ext already reg d1=8c04 d2=10.192.210.28]
20170712:000928905:2376395:capro(25702):MED:[ denial event=1924 IP RRJ-No GRQ msg rcvd d1=8c16 d2=10.140.217.222]