SCN Broken

[Rappy]

I have 2 ip office systems that used to have SCN enabled. Since a few nights ago, they can inter office dial US but we cannot dial THEM!

Remote side- ip office 406v2 ver 3.2.69- ip address on 192.168.239.x/24 subnet
Main Site- ip office 412 ver 3.2.69- ip address on 192.168.1.x/24 subnet

A few nights ago, i moved the ip office on the remote side to its own VLAN because the number of collisions it was causing on our network was slowing the user traffic. It was moved successfully. I then changed the IP trunk line to point to the new IP address of the remote side from the primary site. I can ping the 406 from the main site, i can manage the 406 from the PC running manager on the main site, and they can interoffice dial US, but cannot dial them. I have deleted the ip trunk and recreated it at the main site; i have also deleted the ip route from the main site to the remote site. I added a shortcode to be able to dial them, and i was able to restore functionality of interoffice dialing. HOWEVER- i cannot see the called party's caller ID information when i call them, but they can see my caller id info when they call me! the calls in question are from donkey kong to ext 313 and bugsy seagal to ext 325. I am attaching a trace below:


475418mS RES: Thu 14/4/2011 08:36:34 FreeMem=13130680(9) CMMsg=5 (6) Buff=200 850 1000 1310 5 Links=10861 Elements=154
475534mS AVRIP Tx: v=192.168.15.12 send=49 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
475535mS AVRIP Tx: v=192.168.239.32 send=0 receive=0
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
479500mS PRN: AVRIP receive from pbx c0a8ef20 count = 0
485534mS AVRIP Tx: v=192.168.15.12 send=50 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
485535mS AVRIP Tx: v=192.168.239.32 send=0 receive=1
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
489353mS PRN: AVRIP receive from pbx c0a8ef20 count = 1
495534mS AVRIP Tx: v=192.168.15.12 send=51 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
495534mS AVRIP Tx: v=192.168.239.32 send=1 receive=2
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
499208mS PRN: AVRIP receive from pbx c0a8ef20 count = 2
505535mS AVRIP Tx: v=192.168.15.12 send=52 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
505535mS AVRIP Tx: v=192.168.239.32 send=2 receive=3
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
509060mS PRN: AVRIP receive from pbx c0a8ef20 count = 3
515534mS AVRIP Tx: v=192.168.15.12 send=53 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
515534mS AVRIP Tx: v=192.168.239.32 send=3 receive=4
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
518910mS PRN: AVRIP receive from pbx c0a8ef20 count = 4
525534mS AVRIP Tx: v=192.168.15.12 send=54 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
525535mS AVRIP Tx: v=192.168.239.32 send=4 receive=5
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
528762mS PRN: AVRIP receive from pbx c0a8ef20 count = 5
535535mS AVRIP Tx: v=192.168.15.12 send=55 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
535535mS AVRIP Tx: v=192.168.239.32 send=0 receive=0
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
538610mS PRN: AVRIP receive from pbx c0a8ef20 count = 0
542721mS PRN: LCSE: 01a95804 (0 1012 0); H245 Received close channel: 65793
542721mS PRN: LCSE: 01a95804 (0 1012 0); H245 Sending close channel ack: 65793
542722mS PRN: LCSE: 01a95804 (0 1012 0); Deleting channel 65793
542729mS PRN: LCSE: 01a99494 (0 1012 0); H245 Sending close channel: 257
542730mS H323Evt: v=0 stacknum=50 State, new=ReleaseReq, old=Active id=1012
542731mS H323Evt: v=0 stacknum=50 State, new=NullState, old=ReleaseReq id=1012
542731mS PRN: LCSE: 01a99494 (0 1012 0); Deleting channel 257
542733mS CMLineRx: v=50
CMReleaseComp
Line: type=IPLine 50
Call: lid=0 id=1012 in=0
Product Unknown
Cause=16, Normal call clearing
542733mS PRN: CALL: 0.1011.0 Deleted leaving 0 CMCall objects
542733mS CMMap: a=17.30 b=250.9001 M0
542733mS PRN: Converted to:
542733mS CMMap: a=17.30 b=3.20 M0
542736mS CALL:2011/04/1408:29,00:07:39,001,679,O,313,313,DonkeyKong,,,0,,""n/a,0
542736mS CD: CALL: 0.1011.0 BState=Idle Cut=0 Music=0.0 Aend="DonkeyKong(679)" (17.30) Bend="Line 50" [Line 50] (250.9001) CalledNum=313 () CallingNum=679 () Internal=0 Time=459557 AState=Idle
542737mS CMExtnTx: v=679, p1=28
CMReleaseComp
Line: type=DigitalExtn 3
Call: lid=0 id=1011 in=0
Product Unknown
UUI type=Local [....] [0x03 0x01 0x00 0x0e ]
Timed: 14/04/11 08:37
542738mS CD: CALL: 0.1011.0 Deleted
542739mS CMExtnTx: v=, p1=1118
CMReleaseComp
Line: type=RAS 1
Call: lid=0 id=1118 in=0
BChan: slot=3 chan=20
Product Unknown
542918mS RES: Thu 14/4/2011 08:37:43 FreeMem=13146220(11) CMMsg=5 (6) Buff=200 850 1000 1319 5 Links=10883 Elements=154
545535mS AVRIP Tx: v=192.168.15.12 send=56 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
545535mS AVRIP Tx: v=192.168.239.32 send=0 receive=0
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
546788mS CMExtnRx: v=632, p1=24
CMSetup
Line: type=NoLine 0
Call: lid=0 id=-1 in=0
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ULaw
Product Unknown
546789mS CMTARGET: LOOKUP CALL ROUTE:21 type=100 called_party= sub= calling=632 in=0 complete=0
546789mS CMTARGET: ADD TARGET:21 number= type=100 depth=1 nobar=1 setorig=1 fwduser=
546789mS CMTARGET: LOOKUP CALL ROUTE:21 returned 0
546789mS CD: CALL: 0.1042.0 BState=Idle Cut=0 Music=0.0 Aend="BugsySeagall(632)" (17.26) Bend="" [] (0.0) CalledNum= () CallingNum=632 () Internal=1 Time=1 AState=Dialling
546790mS CMExtnTx: v=632, p1=24
CMInbandTone
Line: type=DigitalExtn 3
Call: lid=0 id=-1 in=0
Product Unknown
UUI type=User2User [TD1\r\n] [0x54 0x44 0x31 0x0d 0x0a ]
Timed: 14/04/11 08:37
546790mS CMExtnTx: v=632, p1=24
CMSetupAck
Line: type=DigitalExtn 3
Call: lid=0 id=1042 in=0
BChan: slot=17 chan=26
Product Unknown
Timed: 14/04/11 08:37
546791mS CD: CALL: 0.1042.0 BState=Idle Cut=0 Music=0.0 Aend="BugsySeagall(632)" (17.26) Bend="" [] (0.0) CalledNum= () CallingNum=632 () Internal=1 Time=3 AState=LocalDial
546791mS CMMap: a=17.26 b=0.0 D1
546793mS CMExtnRx: v=632, p1=24
CMInformation
Line: type=NoLine 0
Call: lid=0 id=-1 in=0
Called[3] Type=Default (100)
Product Unknown
546793mS CMExtnTx: v=632, p1=24
CMInbandTone
Line: type=DigitalExtn 3
Call: lid=0 id=-1 in=0
Product Unknown
UUI type=User2User [TD0\r\n] [0x54 0x44 0x30 0x0d 0x0a ]
Timed: 14/04/11 08:37
546794mS CMMap: a=17.26 b=0.0 D0
546795mS CMTARGET: LOOKUP CALL ROUTE:21 type=100 called_party=3 sub= calling=632 in=0 complete=0
546795mS CMTARGET: ADD TARGET:21 number=3 type=100 depth=1 nobar=1 setorig=1 fwduser=
546795mS CMTARGET: OVERLAP LOOKUP CALL ROUTE:21 returned 0
547335mS CMExtnRx: v=632, p1=24
CMInformation
Line: type=NoLine 0
Call: lid=0 id=-1 in=0
Called[2] Type=Default (100)
Product Unknown
547335mS CMTARGET: LOOKUP CALL ROUTE:21 type=100 called_party=32 sub= calling=632 in=0 complete=0
547336mS CMTARGET: ADD TARGET:21 number=32 type=100 depth=1 nobar=1 setorig=1 fwduser=
547336mS CMTARGET: OVERLAP LOOKUP CALL ROUTE:21 returned 0
548461mS PRN: AVRIP receive from pbx c0a8ef20 count = 0
549605mS CMExtnRx: v=632, p1=24
CMInformation
Line: type=NoLine 0
Call: lid=0 id=-1 in=0
Called[5] Type=Default (100)
Product Unknown
549605mS CMTARGET: LOOKUP CALL ROUTE:21 type=100 called_party=325 sub= calling=632 in=0 complete=0
549605mS CMTARGET: ADD TARGET:21 number=325 type=100 depth=1 nobar=1 setorig=1 fwduser=
549606mS CMTARGET: SYS SC:21 325 3 25 sc=type=Dial code=3XX, num=3N
549606mS CMTARGET: LCR NOT MATCHED:21 (cpn=325)
549606mS CMTARGET: DIAL LINE:21 GROUP=50 SUCCESS=1
549606mS CMTARGET: OVERLAP LOOKUP CALL ROUTE:21 returned 1
549607mS CD: CALL: 0.1042.0 BState=Idle Cut=1 Music=0.0 Aend="BugsySeagall(632)" (17.26) Bend="Line 50" [Line 50] (0.0) CalledNum=325 () CallingNum=632 () Internal=0 Time=2818 AState=Dialling
549607mS CMExtnTx: v=632, p1=24
CMSetupAck
Line: type=DigitalExtn 3
Call: lid=0 id=1042 in=0
Called[325] Type=Default (100)
BChan: slot=17 chan=26
Product Unknown
Display [325]
Timed: 14/04/11 08:37
549608mS CD: CALL: 0.1042.0 BState=Idle Cut=1 Music=0.0 Aend="BugsySeagall(632)" (17.26) Bend="Line 50" [Line 50] (0.0) CalledNum=325 () CallingNum=632 () Internal=0 Time=2820 AState=Dialled
549609mS CMLineTx: v=50
CMSetup
Line: type=IPLine 50
Call: lid=0 id=1043 in=0
Called[325] Type=Default (100) Calling[632] Type=Internal (101)
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ULaw
BChan: slot=250 chan=9003
Product Unknown
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.239.32 port=0
Display [BugsySeagallla]
Cause=16, Normal call clearing
Locale: enu
549617mS H323Evt: v=0 stacknum=50 State, new=NullState, old=NullState id=-1
549619mS H323Evt: v=0 stacknum=50 State, new=Initiated, old=NullState id=1043
549689mS CMLineRx: v=50
CMFacility
Line: type=IPLine 50
Call: lid=0 id=1043 in=0
Product Unknown
UUI type=User2User [turn h323setuptimer off] [0x74 0x75 0x72 0x6e 0x20 0x68 0x33 0x32 0x33 0x73 0x65 0x74 0x75 0x70 0x74 0x69 0x6d 0x65 0x72 0x20 0x6f 0x66 0x66 ]
549918mS RES: Thu 14/4/2011 08:37:50 FreeMem=13132324(10) CMMsg=5 (6) Buff=200 850 1000 1319 5 Links=10874 Elements=154
549949mS H323Evt: v=0 stacknum=50 State, new=Proceeding, old=Initiated id=1043
549954mS CMLineRx: v=50
CMProceeding
Line: type=IPLine 50
Call: lid=0 id=1043 in=0
Product Standard
549955mS CD: CALL: 0.1042.0 BState=Dialled Cut=1 Music=0.0 Aend="BugsySeagall(632)" (17.26) Bend="Line 50" [Line 50] (250.9003) CalledNum=325 () CallingNum=632 () Internal=0 Time=3167 AState=Dialled
549955mS CMExtnTx: v=632, p1=24
CMProceeding
Line: type=DigitalExtn 3
Call: lid=0 id=1042 in=0
Called[325] Type=Default (100)
BChan: slot=17 chan=26
Product Standard
Display [325]
Timed: 14/04/11 08:37
554476mS H323Evt: v=0 stacknum=50 State, new=Delivered, old=Proceeding id=1043
554481mS CMLineRx: v=50
CMAlerting
Line: type=IPLine 50
Call: lid=0 id=1043 in=0
Product Standard
IE CMIEProgressIndicator (30) cs=CMCSITUT (0), loc=CMLPublicNetRemoteUser (4), pd=CMPDInbandPattern (8)
554481mS CD: CALL: 0.1042.0 BState=Ringing Cut=1 Music=0.0 Aend="BugsySeagall(632)" (17.26) Bend="Line 50" [Line 50] (250.9003) CalledNum=325 () CallingNum=632 () Internal=0 Time=7693 AState=Dialled
554481mS CMMap: a=17.26 b=0.0 R1
554483mS CD: CALL: 0.1042.0 BState=Ringing Cut=1 Music=2.0 Aend="BugsySeagall(632)" (17.26) Bend="Line 50" [Line 50] (250.9003) CalledNum=325 () CallingNum=632 () Internal=0 Time=7695 AState=Ringing
554483mS CMExtnTx: v=632, p1=24
CMAlerting
Line: type=DigitalExtn 3
Call: lid=0 id=1042 in=0
Called[325] Type=Default (100)
BChan: slot=17 chan=26
Product Standard
IE CMIEProgressIndicator (30) cs=CMCSITUT (0), loc=CMLPublicNetRemoteUser (4), pd=CMPDInbandPattern (8)
Display [325]
Timed: 14/04/11 08:37
555534mS AVRIP Tx: v=192.168.15.12 send=57 receive=0
requiresvoicemail 0 operational 1 version 2 recordsupported 1
IPaddr 255.255.255.255 hops=0 voice=0
IPaddr 192.168.239.32 hops=1 voice=0
555534mS AVRIP Tx: v=192.168.239.32 send=0 receive=0
PLATFORM: requiresvoicemail 0 operational 1 version 2 recordsupported 1
557999mS CMExtnRx: v=632, p1=24
CMReleaseComp
Line: type=NoLine 0
Call: lid=0 id=1042 in=0
Product Unknown
557999mS PRN: CALL: 0.1042.0 Deleted leaving 0 CMCall objects
558000mS CMMap: a=17.26 b=0.0 R0
558001mS CALL:2011/04/1408:37,00:00:00,003,632,O,325,325,HamiltonUrquil,,,0,,""n/a,0
558001mS CD: CALL: 0.1042.0 BState=Idle Cut=0 Music=0.1 Aend="BugsySeagall(632)" (17.26) Bend="Line 50" [Line 50] (250.9003) CalledNum=325 () CallingNum=632 () Internal=0 Time=11213 AState=Idle
558002mS CMLineTx: v=50
CMReleaseComp
Line: type=IPLine 50
Call: lid=0 id=1043 in=0
Product Unknown
Cause=16, Normal call clearing
558003mS CD: CALL: 0.1042.0 Deleted
558003mS CMExtnTx: v=632, p1=24
CMReleaseComp
Line: type=DigitalExtn 3
Call: lid=0 id=1042 in=0
Product Unknown
UUI type=Local [....] [0x03 0x06 0x03 0x0e ]
Timed: 14/04/11 08:37
558008mS H323Evt: v=0 stacknum=50 State, new=ReleaseReq, old=Delivered id=1043
558009mS H323Evt: v=0 stacknum=50 State, new=NullState, old=ReleaseReq id=1043
558314mS PRN: AVRIP receive from pbx c0a8ef20 count = 0
558417mS RES: Thu 14/4/2011 08:37:59 FreeMem=13144516(11) CMMsg=5 (6) Buff=200 849 1000 1319 5 Links=10881 Elements=154

********** Warning: Logging to Screen Stopped **********



Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

I just read that you changed the subnet and it stopped working.
Do you perhaps have an iproute that is not correct?


BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

would make sense right?

however please note the following:

1. i can manage the 406 from the 412's VM server (i can hit the application/device on the remote subnet, which i just changed)

2. i can ping the 406 from the 412 side, and the 412 from the 406 side

3. i have verified the routes AT the 412 side and on the 406 side

4. i have traced traffic from the 412 side to the 406 side THROUGH the router, through the WAN and to the 406 side, and in reverse

It cant be a routing issue. If i can see the 21x extension which resides on that same 406, what is going on? SCN would be totally broken if i couldnt do that. but, as i have stated. i was able to dial 21x without the need for a shortcode, and the caller id info (i think this is key!) is automatically displayed. I thought that the caller ID info was pulled from the SCN settings on the other side, ie, ext 214= Dr. No therefore DISPLAY [DR NO].

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

Put it back on the old subnet and see if it works.
When it does then you have a problem in the new subnet.


BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

Thank you for the suggestion, and i dont mean to sound stoic, but that is not an option.

There were about 700 collisions per day on the switch port where the IPO is located. Putting it back on the user's subnet would take me back to square one, and users' legitimate traffic would be affected by those collisions.

There is no firewall or any impediment that is blocking the IPO's from communication with one another. This is simply a matter of the IPO not working as intended. As i have stated before, we have changed the IP address on this 406 before without any issue. We have also had IPO's on other sites now closed in which the SCN simply worked- we added new users, deleted users and so on and so forth. When we dialed those extensions, the routes were there and the SCN was joined over those ip trunks as expected. Could it be that Avaya does not like any IPO's to reside in specific subnets? it currently resides in 192.168.239.x. could it be that only subnets 192.168.0.x-192.168.99.0 are supported? Yes, i know i am reaching, but i have run into issues just as strange with Avaya.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

Rappy, i have never seen this kind of behavior coming from the ipoffice itself in the 6 years i work with it.

After removing the other sides, did you remove the iptrunks too?
What are the iproutes in both ipo's???


BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

yes, i removed the IP trunks, then rebooted.

the 406 points 192.168.1.0 to 192.168.239.1 (239.1 being the default gateway); dest LAN1

the 412 points 192.168.239.0 to 192.168.1.1 (1.1 being its default gateway); dest LAN1

I see why you asked this, but like i said, i can dial other extensions on that IPO without the use of shortcodes. The 31X extensions are the ones giving me fits.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

Then there must be something blocking it.
There must be a match to this 31X in the system.


BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

But, dont you think it would be blocking it entirely, not just for ext 31x? I figured if i could not reach 21x and 31x we would have a problem. But, it's only 31x. My routers/switches make no determination as to where 21x or 31x are, as a matter of fact, they dont care! They only care about the IPO at 239.x- and to forward traffic to it. Once that is done, they couldnt care less. There are no firewalls in between the IPO's, and the WAN, nor between the two IPO's and the VM servers.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

Check for other shortcodes that could have issues with 31X.


BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

there are no other shortcodes which could cause issues when dialing 31x. I will continue to look and prod around the IPOs. I may bounce the routers overnight and see if that helps any, even though they arent blocking anything, it could be that the switches/routers have a stale route or persistent route in their cache causing problems.

I will report any finding back. in the meantime- i am open to suggestions (other than going back to the User's LAN ).

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[mattKnight]

Collisions suggest a duplex mismatch...

You haven't forgotten that the IP412's Ports are Half duplex have you.

You'll need to adjust your data switch config for that.

I may bounce the routers overnight

What sort of routers? do they have any level of packet inspection or ALG?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Rappy]

I have placed the 406 to be half duplex 100M; i made this change for the data switch as well. I have yet to do anything for the 412, but it has always been half duplex/100M and the change has been made to the data switch on the 412's side as well.

i use cisco routers (2800 series ISR). I have the ability to view the payload, but not without a performance hit. This is something i would have to do after hours.

I also have something else to report- as an experiment, i deleted an extension which was not in use. I then re-added that user and mapped him to the extension i had just deleted (deleted Conf Room, ext 399, added IT HELPDESK, ext 399), and guess what? i can see the caller ID information for that particular user. WTH!

I then tried to change the user name for a user whose name was "CBANANA" to just "C." Merged the config- i STILL cant see her caller id info before she picks up. but i will bet that if i was to delete her, and readded, as i have done above with EXT 399, I WOULD BE able to see the caller id info right away.

FYI: regarding the duplex mismatch- even after the 406 and the data switch were set to half duplex/100M, there were still collisions on that switch port. i have replaced the cabling between the 406 and the switch to ensure that i didnt have a bad cable, and the collisions kept happening. i saw this behavior displayed as well with another IP office 406 V1 plugged into the same switch.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

The 406 is full duplex, the 412 is half duplex.
So after deleting and recreating it works.
This means that the other IPO have learned it.
It sounds like you did not reboot the other ipo after the IP change.


BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

OK!

According to Avaya and a case i opened with them, the following are the recommended settings:


"The IP406v1 unit is a hub and whatever is connected directly to the LAN
port should be set 100 half duplex.

So this confirms you do indeed have a 406v1 system and the LAN ports
support 100 half duplex."

From: [ENTRY OMITTED] (Martie) [mailto:[ENTRY OMITTED]@avaya.com]
Sent: Wednesday, March 16, 2011 11:22 AM

After i changed the IP address, i rebooted the IPO 412. Had i chosen not to do that, i wouldve saved myself a 30 minute trip in the rain at 1030 at night to come unplug the PRI lines which lock up after the IPO is rebooted.

It's just funny how it's working and NOT working at this point. I do have backup configs on which i can fall back, and start over. i honestly would hate to have to come back in after hours and restore a configuration, just to change it and not have it work again.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[mattKnight]

Soory,

But you need to be clear about this

Do you have a IP406V2 or a V1

If you have a V1 then Avaya are correct. If you have a V2 they are wrong

Easy way to tell - do you have any digital extension ports on the front of the 406 usnit?


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Rappy]

It is an IPO 406 V1.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[tlpeter]

You really have problems.
A pri should not lock up after a reboot.

BAZINGA!

I'm not insane, my mother had me tested!

 

[Rappy]

Be that as it may, it has been the case since we got this thing. The carrier blames Avaya for not timing properly, and Avaya blames the carrier for not timing properly. The cabling guy has tested the extension from the DEMARC and noted that there are no issues with cabling, and we are left holding the bag.

I can deal with minor discrepancies such as those. I just hate it when stuff that just should work, and has, stops working. Very annoying.

Beets? Yes! Ask me how I feel about Beets! I like Beets!

 

[amriddle01]

This is simply a matter of the IPO not working as intended.

How can you say that, when all the evidence points to a networking issue of some sort?
Lets not forget it worked OK until you chaged subnet, after that it didn't work, that would have to be the worlds biggest coincidence if the IPO developed a fault relating to networking at that exact time you made a network change.
Just because you can't figure out what the network issue is doesn't mean you should move on to blaming something else, I think you need to dig into the networking side deeeper.

I would run wireshark traces of each system and compare them side by side, and I would bet that all the voice networking traffic leaves each IPO OK, but some of that traffic is not reaching the far side, then you know for sure if it's the network or the system(s)

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[Rappy]

I knew someone would get their feathers ruffled about making the slightest comment about "Avaya not working as intended." Dont shoot, i am just repeating myself!

Dont take it personal, stuff breaks and does not work as intended all the time. I know it would seem coincidental, but you are not taking into consideration the other items (i can dial ext 21x without shortcodes, i can delete an extension 31x and recreate it, and it works just like it used to, caller id and everything).

I am very diligent about exploring every option, even if it means having to say I messed something up. I am on site now and running wireshark traces, and i can see the traffic from the 412 traverse the WAN, hit the internal gateway, get to the 406 side, traverse to the VLAN and hit the 406. i have also run traces from the router to the 406 and the 412 successfully.


Beets? Yes! Ask me how I feel about Beets! I like Beets!