Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

why is voice networking (SCN) so intermittment

Status
Not open for further replies.

nitz01

IS-IT--Management
Sep 2, 2005
39
0
0
US
is there any particular reason or setting, why SCN works intermittently, even though the VPN tunnel is always up and extension dialing is always possible?
if this is of any information there is only an active vpn connection from the main IP office to the branch office when no calls are in progress. is this the general behavior, where connections are only initiated in this direction to exchange SCN info.

regards
 
excuse the typo..intermittent
 
I think the two systms will need to be talking all the time for the SCN to be up and work correctly

[cheers]
 
well, even though the connection is iniated by the main ip office communication can be two way on that connection once made. however, i'm not any closer to knowing what's going on. i guess i will have to open a support ticket with avaya :(
 
SCN is like RIP (in fact in Monitor you can find options for AVRIP), ie. the IP Offices regularly (every few seconds) send out information and receive information about each other - so to do SCN over any VPN requires that VPN link to be permanent. Having the VPN link only for the duration of calls will lead to issues.
 
i think there is some misundertanding. there is a dedicated site to site VPN tunnel between the two sites, and any traffic between the two ipoffices is readily encrypted and forwarded. i was just commenting on the fact that i rarely see a connection with the branch office as the source and main office as destination, unless there is a call in progress.
e.g.
main 192.168.1.13
branch 192.168.5.13

no call in progress:
UDP 192.168.1.13 49217 192.168.5.89 49509

call in progress:

UDP 192.168.1.13 49217 192.168.5.89 49509
UDP 192.168.5.89 49508 192.168.1.13 49216
UDP 192.168.1.13 50795 192.168.5.89 50795
TCP 192.168.1.13 4107 192.168.5.89 1720
 
In this case use the monitor and select AVRIP to monitor what is coming in and going out of the IPO as per sizbut.



[cheers]
 
What kind of VPN router you are using?

We have a site to site vpn using Checkpoint and QOS setup and it works great. It connects two site which are 3000 miles away with one vmpro server.
 
vpn between checkpoint secure platform ng with a nokia IP30...we are not using QoS, and does not seem to be a problem since call quality is never an issue(small networks lots of bandwidth available). in addition, QoS would have only been possible on local networks/gateways since we are utilizing public lines.

not having QoS does however make it difficult to eliminate issues. please see avrip logs below. not to sure how to read these logs, but correct me if i am wrong..am i not supposed to be seeing some type of Rx traffic. i wonder if its the IP30 misbehaving??

no calls in progress:
(small office)
1mS PRN: LAW=U PRI=0, BRI=0, ALOG=4, ADSL=0 VCOMP=16, MDM=0, WAN=0, MODU=0 LANM=0 CkSRC=0 VMAIL=0(VER=0 TYP=2) CALLS=0(TOT=53)
3002mS PRN: +++ START OF ALARM LOG DUMP +++
3002mS PRN: ALARM: 05/01/2006 14:31:06 IP 401 NG 3.0(69) <TLB Data Error> CRIT RAISED addr=00de5710 d=5 pc=ff60687c ff606850 ff606784 ff770520 ff770630 ff770aa0
3002mS PRN: +++ END OF ALARM LOG DUMP +++
5266mS AVRIP Tx: v=192.168.1.13 send=8288 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
15266mS AVRIP Tx: v=192.168.1.13 send=8289 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
25266mS AVRIP Tx: v=192.168.1.13 send=8290 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
35265mS AVRIP Tx: v=192.168.1.13 send=8291 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
45266mS AVRIP Tx: v=192.168.1.13 send=8292 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
55266mS AVRIP Tx: v=192.168.1.13 send=8293 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
65265mS AVRIP Tx: v=192.168.1.13 send=8294 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
75265mS AVRIP Tx: v=192.168.1.13 send=8295 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0


(406)

0mS PRN: LAW=U PRI=1, BRI=0, ALOG=4, ADSL=0 VCOMP=5, MDM=2, WAN=0, MODU=4 LANM=0 CkSRC=1 VMAIL=1(VER=2 TYP=1) CALLS=1(TOT=1535)
5870mS AVRIP Tx: v=192.168.5.89 send=11354 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
15870mS AVRIP Tx: v=192.168.5.89 send=11355 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
25870mS AVRIP Tx: v=192.168.5.89 send=11356 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0



 
first thing i see is a TLB error
i dont like to see those errors :)
 
and for us non-programmers. what is a TLB error and what causes it?
 
can be a lot
search for fatal tlb error on this forum and you find a lot about it
last time i had it i had to erase the config start all over again
in sysmonitor you can look for errors
check it and maybe you need an engineer to handle it
 
they are both running 3.0(69)..latest stable build in my opinion
 
I am having the same kind of problems.... SCN just "falls over" for no reason.... No one can seem to answer the question why..... I will send configs to anyone who thinks they can help!! I know it works and I know its stable cos I have seen it workin perfectly in the lab!!

I am using draytek routers and 2mb ADSL.

Any ideas?
 
i have no experience with draytek, but i got my SCN working reliably for about 5 days now by changing the IPSmallOffice to a dynamically assigned ip and rebooting the nokia ip30. So I am quite certain that my issues lie within that crappy ip30 firewall.

if you have the luxury try testing the setup with different firewalls.
 
Steve,

Have just recently done a job networking 406's over Draytek VPN's.

Things to check, VPN's are set to dial both ways on the draytek. SCN is ticked in the IP Line config. Draytek boxes have latest firmware on board. extn dialing by shortcode is setup, so that even if SCN fails you can still extn dial.
 
Nitz01,

Dynamic IP is definately not good for IPNetworking, I assume you are using DHCP reservations in this case, if not are you reprogramming the line every couple of days?

Check Voice Networking is checked in the line setup.

VPN's that only close and reopen based on traffic loads are no problem for the SCN, although use a time out longer than 5 minutes for disconnect on idle.

I would put in extn dialing by shortcodes with the IP trunk set as the line to dial on, in case you haven't already.
Also make sure you specify the same codec on each side of the line as left on auto, you do get funny problems during the establishment of the call.
 
gweebie,
normally i wouldnt leave as DHCP client, but the IP30 which is also the DHCP server, has a bad habbit of not considering static ip's as part of the encryption domain (hence preventing outgoing encrypted traffic from the static host). however, it does use reservations and never gives an ip out twice so hasnt been a problem. i have shortcodes on both sides for extension dialing, but central voicemail, which relies on SCN, was the issue not calls. i will try to specifically set codecs instead of leaving them as auto, but everything seems kosher for the last five days.
thanks

oh and voice networking is of course checked.
 
I would add that its probably similar problem to the problems people list with ip phones disconnecting over vpn tunnels. Tunnels time out to some extent or another even with keep alive turned on.

Change VPN hardware. Also could be issues with internet provider or providers on both ends.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top