Avaya to Lync

[larmi]

We are moving from Avaya to Lync. We consulted with our vendor to help us with the transition.
However, it's impossible to get through to them so I'm looking to the forum for help so that I can do this on my own.

This is what I know...
-A trunk was created for Lync = Trunk 98 (23 members)
-A route pattern was created = route pattern 98
-A new block of extensions were setup as stations and were routed to Lync by our vendor. Extensions 6602 to 6623 I believe. All I see is that each of those extensions were added to UDP and AAR Analysis

I want to convert my station (extension 5205) over to Lync, so I added my extension to UDP and AAR Analysis, like the others, but it is giving me the error tones.

Any other places I should be checking?

Thanks so much!

 

[ZeroZeroOne]

Lync (or Skype for Business) has to be considered as another phone system with separate dial plan and rules so you'll need a matching entry in Lync to accept your extension. Everything may be correct in CM but Lync doesn't know what to do with "5205".

So if Lync extensions 6602 to 6623 exist (or there is a normalization rule that converts 4-digits to Lync extensions) then you need to create Lync extension 5205 or edit your Lync profile to be that number.

I hope that helps.

 

[larmi]

I built the normalization rule and verified that it is accurate. I can recognize that this is Avaya error tones I am hearing. So it sounds like it's not making its way out of Avaya. Is there anything else that I can check in Avaya ?

 

[ZeroZeroOne]

You could run a list trace in CM and see what's happening when you dial a 6xxx Lync extension and compare that to dialing 5205.
The next step depends on if Session Manager is set up. If your trunk group goes to ASM then you'll also need to check the dialing rules there. CM may be passing to ASM but ASM does not know where to go after that, for 5205.
If you have Session Manager then you could watch the SIP traces, comparing calls to 6xxx and 5205.

 

[larmi]

Working...

time data

15:26:47 active station 6200 cid 0x39b2
15:26:47 G711MU ssff ps:20
rgn:241 [10.0.44.142]:16488
rgn:1 [172.28.2.37]:47312
15:26:47 dial 6621 route:UDP|AAR
15:26:47 term trunk-group 98 cid 0x39b2
15:26:47 dial 6621 route:UDP|AAR
15:26:47 route-pattern 98 preference 1 cid 0x39b2
15:26:47 seize trunk-group 98 member 11 cid 0x39b2
15:26:47 Setup digits 6621
15:26:47 Calling Number & Name 6200 NO-CPName
15:26:47 G711MU ssff ps:20
rgn:241 [10.0.44.142]:16488
rgn:1 [172.28.2.47]:2064
15:26:48 Proceed trunk-group 98 member 11 cid 0x39b2
15:26:49 Alert trunk-group 98 member 11 cid 0x39b2
VOIP data from: [172.28.2.47]:2064
15:26:58 Jitter:2 0 0 0 0 0 0 0 0 0: Buff:15 WC:5 Avg:2
15:26:58 Pkloss:3 0 0 0 0 0 0 0 0 0: Oofo:0 WC:3 Avg:3
VOIP data from: [172.28.2.47]:2064
15:27:08 Jitter:2 2 2 2 2 2 3 3 3 0: Buff:17 WC:6 Avg:2
15:27:08 Pkloss:3 0 0 0 0 0 0 0 0 0: Oofo:0 WC:3 Avg:0
15:27:12 active trunk-group 98 member 11 cid 0x39b2
15:27:14 idle station 6200 cid 0x39b2



Not working...

time data

15:20:28 active station 6200 cid 0x38d2
15:20:28 G711MU ssff ps:20
rgn:241 [10.0.44.142]:16488
rgn:1 [172.28.2.37]:47020
15:20:28 dial 5205 route:UDP|AAR
15:20:28 term trunk-group 98 cid 0x38d2
15:20:28 dial 5205 route:UDP|AAR
15:20:28 route-pattern 98 preference 1 cid 0x38d2
15:20:28 seize trunk-group 98 member 5 cid 0x38d2
15:20:28 Setup digits 5205
15:20:28 Calling Number & Name 6200 NO-CPName
15:20:28 G711MU ssff ps:20
rgn:241 [10.0.44.142]:16488
rgn:1 [172.28.2.47]:2068
15:20:28 Proceed trunk-group 98 member 5 cid 0x38d2
15:20:29 denial event 1166: Unassigned number D1=0x892e D2=0x520f01
15:20:29 idle trunk-group 98 member 5 cid 0x38d2
15:20:35 idle station 6200 cid 0x38d2

 

[ZeroZeroOne]

It looks like CM is routing the same with UDP and AAR since both calls are hitting trunk group 98.

You may need to add an entry to either the public-unknown-numbering or private-numbering tables. That could cause a denial event.
Check Route Pattern 98 and trunk group 98 for either public or private numbering and check those tables for entries for the 6xxx range. You'll probably have to add a similar entry for your extension.

 

[larmi]

Sorry! I found out that it wasn't set up correctly on the Lync side. We had two normalization rules that were cancelling each other out. However, I really appreciate all of your help in attempting to troubleshoot with me! Thanks again!