ESN5 / TCOS / NRS 1

[NortelGuy1979]

Hello all,

For the first time, I'm setting up ESN5 on our SIP trunks so we can use NAUT instead of depending on the NCOS of the SIP trunks and prompting EVERYONE to enter an authcode...

We have a CS1KM, a CS1KE, both at 6.0, and a standalone NRS. Currently, all the SIP trunks are NCOS 0 and LD calls from the CS1KE tandem thru the CS1KM where they are prompted for an authcode (SIGO = STD and AUTH = YES).

We'd like to start using NAUT with ESN5 so we can get TCOS marker and use the NCOS of the originating set at the CS1KE for authorization.

When I turned on ESN5, all my call routing broke because the NRS sees the called digits as 10(x)9+1+NPA-Nxx-xxxx where the (x) = the NCOS of the originating set. In an old ISDN P2P environment, this was transparent... but not w/ NRS in the middle.

Do I have to put 10(x) in front of every routing entry in my NRS? Or is there a one of the numbering fields on the endpoint that accounts for that?

I haven't been able to find any documentation regarding this except in the old IPT 3.0 documentation; nothing in the new NRS docs.

Any help is appreciated in advance.

Thanks!
-Matthew

Matthew - Technical Support Engineer

 

[allenmac]

Matt,

I use and have used ESN5 on all of my switches networked with both H.323 and SIP trunks for years.

I don't have to include the TCOS in the NRS, I just have to make sure that the calls are marked properly, and that all the country codes are correct in my switches.

If I turn on D-Channel messaging, I see the TCOS digits in the messaging, but the NRS doesn't use them to determine how to route the call.

Can you post some additional information, like RDB, D-Channel, Net-Info from CDB, etc. Anything additional you can provide will help narrow down the problem.

 

[NortelGuy1979]

I've been given the suggestion that the trunks and route need to be actually OUT'd and rebuilt to change the SIGO from STD to ESN5, and then when the SIP gateway registers them (when I rebuild it) it will handle it w/o any issue, and no modification to NRS.

We've simply been disabling all the VTRK channels in order to make the change on the RDB.

I'll let you know if that works when we get a chance!
-Matthew

Matthew - Technical Support Engineer

 

[allenmac]

You should not have to out and rebuild the trunks and route.

You can make the change by disabling the route, then making the change to ESN5 signalling.

 

[NortelGuy1979]

@AllenMac - you're 100% correct - it worked using LD 32 DIS VTRM / ENL VTRM commands. When they re-enable and re-register, the numbering translation is all transparent.

Prior, I had simply been disabling all the channels manually (LD 32) to make the change.

Thank you so much!
-Matthew

Matthew - Technical Support Engineer

 

[NortelGuy1979]

Hi All,

An update on this - ESN5 is working fine between the two CS1K sites, and *one* out of two SRG50 sites. One of those is a BCM2? software release 2, the other is a BCM3 software release 6. (disclaimer - I know very little about BCM and SRG).

Both of these sites have their own PRI with DID numbers. So even when the SRG is in normal mode, the SRG is still in control of the inbound call on the PRI and sends the call via SIP to the CS1000, where it rings the set.

This is all fine and great on the newer SRG, it seems to know to send a TCOS marker right away. We didn't change anything.

On the older SRG, it did not send TCOS. We had to manually insert the numbers 107 (could've inserted 100 thru 107 I suppose) into the call before it hit the SIP. The NRS continued to work fine (107 is in there as a zone code for that site I believe) and then the CS1000 was receiving 107xxxx on the calls, as I would expect w/ TCOS, and it worked.

Any idea why one SRG would pick this up w/o ANY reconfiguration, and the other wouldn't? We went thru the dialing plan and route configuration of each SRG literally screen-by-screen trying to find the difference, and couldn't.

Any help would be appreciated; I know little about SRG so my apologies in advance.

Thanks!
-Matthew

Matthew - Technical Support Engineer

http://www.linkedin.com/pub/matthew-heavner/25/19/367

 

[Firebird Scrambler]

Changing SIGO to ESN5 from STD or back to ESN5 etc can be done without having to out the route by doing the following first.

sch1453
when trying to change SIGO prompt on virtual route

LD32 PROMPT DIS - VTRM - 0 - RT NUMBER

ENL- VTRM - 0 - RT NUMBER

Found on release 4.0 onwards for call servers

unable to change SIGO from STD to ESN5 on virtual route SCH1453 returned Cannot change data while route still enabled.

follow above soloution summary then carry out change then re-enable VTRM

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[NortelGuy1979]

I was able to make the change (once I found those DIS VTRM / ENL VTRM commands), but the issue we had after that was that one of the SRG50's didn't recognize it; the other one did.

So one was a BCM3 R6.0 sending TCOS, the other was a BCM2 R2.0 not sending TCOS. The configuration of both looks identical. We finally gave up and manually inserted digits to look like a TCOS marker on the BCMR2, and it worked.

Any ideas as to why the newer one automatically inserted TCOS?

-M

Matthew - Technical Support Engineer

http://www.linkedin.com/in/matty79

 

[Firebird Scrambler]

Forget my last reply as it had already been given out.

As the link is via a BCM with SRG, I think there has to be some major changes in your spn tables to force calls back down the SIP link to the BCM.

I know of a customer with around 4 BCM's with SRG that have their incoming DID calls route into the CS1000, for it to bounce back to a registered IP phone of the CS1000 back at the BCM end. The SPN tables were routed with codes such as 11,12,13, 14 etc and DMI's were used to map with the ESN5 messaging such as your one of 109 etc.

I'll have to find out more for you as it wasn't one of my sites that I worked on much.

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[NortelGuy1979]

Thanks; any help is greatly appreciated. We got it working via a workaround, but it seems messy.

In normal mode, the only time the SRG is sending any call to the CS1K is when someone calls the DID that terminates physically at the SRG. SRG sends call via SIP to CS1K to phone which is (in normal mode) registered to CS1K.

Of course, since SIP route on CS1K is now ESN5, it expects TCOS. The R6 SRG sends it; dunno how it knew to because we didn't change a thing. The R2 SRG didn't, so the CS1K rejected the call. We inserted the digits 107 into it which were already programmed due to zone dialing, but were absorbed, we just changed it so they weren't absorbed. CS1K registered 107 as the TCOS.

Hope that made more sense

-Matthew

Matthew - Technical Support Engineer

http://www.linkedin.com/in/matty79