Access a remote systems trunks 1

[ccarmock]

In a network of say 2 BCM50's connected by H323 if the private DN length is 4 digits this works fine for set to set dialling between the systems. However if BCM B has no PSTN trunks and I want it to have access to the trunks on BCM A. I can setup a remote package etc.

However how to I allow BCM B to dial more then 4 digits across the network calls for those calls that are destined for the PSTN via BCM A?

 

[ccarmock]

Probably bad form to followup my own post (sorry!)

I did get this figured out - it seems that if I dial the access code for BCM A and then dial one of it's Line Pool access codes then the system does not impose the private network number length.

However what I do find that unless I dial VERY slowly digits get missed from my dial string when it goes out to the PSTN.
I have tried to dial out over an analogue PSTN line connected to BCM A as well as a BRI trunk connected to BCM A in both cases unless BCM B sends PSTN digits very slowly I see them being missing when the number goes out over the trunk.

Has anyone else seen similar? Is there a fix?

 

[getsomesun1]

Did you try to build a second H323 route that was public? If you have everything else built correctly and remote package defined this may be your problem. Your existing route has a DN Type of Private. Make another route that is Public (unknown) and have a destination code of 9 point at the new Public Route.

 

[ccarmock]

Yes I tried building a public route from the 'remote' BCM and have also tried removing the H323 config on both systems and switching to SIP trunking.

Both changes result in the same- loss of digits when the remote BCM tries to dial out over the central BCMs trunks.

Both systems are fully patched Release 6.0 systems

in all cases calling from an extension on one system to an extension on the other works just fine, the problem only occurs when trying to access a remote trunk.

 

[getsomesun1]

hmmm. Well you need all the stuff above. is your Absorb digits set to 0 on the Public route so that all the digits will be transmitted to the far side?

 

[ccarmock]

yes absorb digits is set to 0. When I have BCM Monitor running against the central system I see the incoming network call and then it seizes a line but the dialled digits from the remote end are sometimes missed when dialling on that external trunk.

I currently only have an MCDN keycode on the central system not the remote - is that related? From what I read it's needed for centralised voicemail or if names etc need to pass between systems.

 

[getsomesun1]

Oh Snap! Well, without spending time reading the manual I would say that could very well be your problem. I have done interoffice dialing without MCDN but not Accessing trunks from another switch. Hmmmmmm Maybe someone else will chime in to confirm but I am kinda thinking that may be your issue.

Good luck.

 

[ccarmock]

Thanks for following up - I am wondering that. I haven't seen any Avaya Docs that clearly state that MCDN is needed for this type of tandem calling, just centralised voicemail.

However since MCDN does help handling of signalling between systems I did wonder if it might be needed

 

[hawks]

MCDN needs to be on both systems to create a true Private Network. It allows both systems to act as one where you get caller id, Network Call redirection, Centralized VM if you want, and other features take a look at the Networking Configuration Guide for more information.
That being said if you are just looking to use the main system trunks from the remote side you can do that the way you’re trying to you just have something missing. Something is being lost at the main site if you see all the numbers coming in but not going out.
Try it using DISA first and see if you can call out that way. Build a DISA DN on the main site and allow for the remote package you have built. Then call in from the remote side and see if you can dial out using DISA.

 

[ccarmock]

Yes I am very much just trying to allow one system to use the trunks of the other.
I will try a DISA config.

The issue seems to be that when the central systems line is seized there is a slight pause and during that time any dialled digits from the remote system are lost. Dialling very slowly digit by digit will allow the right number to be called.

You are confirming my thoughts that strictly speaking for this to work MCDN shouldn't be needed.

 

[ccarmock]

I have not had a chance to try DISA yet but I have had a chance to try this on two systems that both have an MCDN keycode now
Unfortunately I get the same result - extensions calls across the network are fine, but when accessing a remote systems trunks when dialling the external number randomly digits are missed unless dialling is VERY slow

 

[ccarmock]

I finally solved this one.

It was a problem with the source system (ie the one without it's own external trunks).

Under Dialing Plan -> Public Network the DN length of '9' in the Public network DN lengths was set to 4 I could see from BCM monitor that after 4 digits it would route the call and send those digits to the public network trunk on the central system and then as more digits were dialled they'd get randomly lost.

Increasing the DN length of 9 to 16 solved the problem - the source system captures all the digits and sends them in one block an the call dials out on the public network of the central system reliably now.

 

[snowman50]

At least you updated us and resolved the issue.

It's nice to see people explain how they solved it and not just say solved.

star for you

 

[hawks]

Nice....that pesky little DIALING PLAN

 

[ccarmock]

yes it's working well now - I hadn't considered messing with that initially