Standalone CS1000E Rel 6.0 SIP Trunking with CS1000M Rel 4.5

[ktse1210]

Hi all,
I have managed setup a standalone CS1000E Rel 6.0 system with SIP Trunking.
I am now trying to get it to connect to a CS1000M Rel 4.5 system (SSC-based).
Yes, the Rel 6.0 only has SIP Access Ports while the Rel 4.5 has both H323 and SIP. Now previously, we tried to get H323 and SIP working together but it failed as at that time it seems that both hates each other and will not work together.
Now, I will be patching the COTS SS on the Rel 4.5 soon and I will be trying to get H323 and SIP to run together again.
Here are my questions:

1) Do you reckon, the COTS SS on the Rel 4.5 system once patched with the latest deplist, will be able to handle both H323 and SIP Trunking simultaneously?
Anyone had any experience with it?

2) As the Rel 6.0 is a standalone system (say in Site A) and I need the phones there to be able to dial internally to talk to the Rel 4.5 system (in Site B) via SIP Trunking.
I have already setup SIP trunking on both sites system.
I have experience in setting up SMGs and Branch Offices but for these standalone system talking to each other via SIP. What else do I need to setup?

Help anyone??? Please??

 

[KiwiOz07]

Hi ktse1210,
Standalone mode means that the physical signalling server is running the NRS only. Co-located is where it is sharing a signalling server with Line TPS etc.

allenmas is correct in saying:
"The Primary NRS must be running at or above the highest release in the Network. The Primary NRS in your case should be running 6.0 software."

So here is how I would do NRS in your network:
Main Site A (Rel 4.5)- Alternate NRS (when this site upgraded to Rel 6)
Remote Site B (Rel 3.0) ----> This will be upgraded to Rel 6.0 --> Primary NRS


The following is a exert out of the Nortel Manual "Planning the Network-wide Upgrade" that states the NRS must be Rls 6:
Network Routing Service
In order to support new features, the NRS must be running the latest software release in the network. In most cases, if the entire network is being upgraded, upgrade the NRS first.
It is possible to operate CS 1000 Release 6.0 nodes with CS 1000 Release 5.5 NRS for a short time if the upgrade logistics require this. Some new feature capability may not operate.
Note that the NRS must be the same software release as the Alternate NRS in order to synchronize the databases.
The NRS can operate in two modes: stand-alone or co-located. A stand-alone and a co-located NRS are handled differently during a network upgrade. If the NRS is co-located with a gateway, the entire node must be upgraded.

 

[ktse1210]

Thanks guys.

What about just SIP Trunking between 2x Standalone systems?
Say Site A and Site B are both standalone system and I have to get SIP Trunking to just work between them?

Cheers!

 

[KiwiOz07]

You still need the NRS for SIP Trunking between 2x Standalone systems.

 

[ktse1210]

Thanks KiwiOz07.

I did a vtrkShow on the Site A's oam prompt of the SS and it shows me that SIP and H323 is enabled on the same D-Channel and Channel ID ranges, etc.
However, when I did a SIPGwShow, nothing comes up at all. It just gives me another oam prompt.

I should be seeing something like the below right?
oam> SIPGwShow
SIPNPM Status : Active
Primary Proxy IP address : 10.154.2.230
Secondary Proxy IP address : 0.0.0.0
Primary Proxy port : 5060
Secondary Proxy port : 5060
Primary Proxy Transport : UDP
Secondary Proxy Transport : UDP
Active Proxy : Primary :Registered
Time To Next Registration : 9 Seconds
Channels Busy / Idle / Total : 0 / 30 / 30
Stack version : 4.0.0.30
TLS Security Policy : Security Disabled
SIP Gw Registration Trace : OFF
Output Type Used : RPT
Channel tracing : -1


However, I guess the SIP Gateway is not really running, huh?

 

[KiwiOz07]

Hi,
Here is my output. The problem you have is your configuration Will not be supported by Nortel. Your SIP appears to be up but it may never work properly as your NRS should be on Rls 6.

oam> SIPGwShow
SIPNPM Status : Active
Primary Proxy IP address : IP removed
Secondary Proxy IP address : IP removed
Primary Proxy port : 5060
Secondary Proxy port : 5060
Primary Proxy Transport : UDP
Secondary Proxy Transport : UDP
Active Proxy : Primary :Registered
Time To Next Registration : 12 Seconds
Channels Busy / Idle / Total : 0 / 106 / 106
Stack version : 4.0.0.30
TLS Security Policy : Security Disabled
SIP Gw Registration Trace : OFF
Output Type Used : RPT
Channel tracing : -1

 

[ktse1210]

Yup, agreed.

I think instead of going down the path of moving the Primary NRS to the Rel 6.0 and programming in tonnes of Routing entries, I might go ahead with the Collaborative Server method where, I can run Primary NRS's on both Rel 4.5 and Rel 6.0.

 

[allenmac]

ktse1210,

You can certainly have different primary NRS domains communicate and route calls using collaborative servers, but you will also have other limitations imposed by doing this.

I think you may be confusing the issue with the NRS.

NRS is meant to be the central depository of your numbering plan for all of the endpoints in your network. With only a handfull of sites, there is no reason to start thinking about collaborative servers, as each NRS can handle something like 20,000 routing entries.

Remember, for your whole enterprise, you assign a single NRS as primary, and that is the NRS that you manage by configuring all the endpoints, and routing entries. Another instance of NRS on your enterprise is designated the Alternate, and is used either for load sharing (Rls 6), or as a backup to the Primary in case of network connectivity failure, or device malfunction. All other instances of NRS in your enterprise are designated as failsafe, and only come into play if both Primary and Alternate sites are unavailable. In order for the Failsafe sites to still route calls to other locations, endpoints should be configured as Static with Static IP addresses where possible.

It is relatively inexpensive to purchase a signaling server, and configure it's NRS role as Standalone. This would become your Primary NRS, and you could have it physically in any of your offices - pick the one with the best network connectivity, and always upgrade it before you upgrade any other site to a higher release. The Alternate and Failsafe NRS instances can be running lower versions of software to match whatever version of PBX software is running on their associated call servers.

If I were you, here is what I would do (just my opinion):

Main Site A (Rel 4.5) ----->Aadd standalone sig server with Rls 6 software configured as Primary NRS
Remote Site B (Rel 3.0) --> Upgrading to Rls 6, designate this site as Alternate NRS
Remote Site C (Rel 4.5) --> Failsafe NRS
Remote Site D (Rel 4.5) --> Failsafe NRS
Remote Site E (Rel 4.5) --> Failsafe NRS
Remote Site F (Rel 4.5) --> Failsafe NRS

 

[ktse1210]

Hi Allenmac,
Thanks for your explanation and it really helped. Anyway, my project has rejected going down the Collaborative Server method.

It looks like we are going down the method that you have just explained coincidentally. However, there's just 2x things that are different from your recommended setup that we are carrying out:


Main Site A (Rel 4.5) -----> Add standalone sig server with Rls 6 software configured as Primary NRS
(We won't be getting a standalone SS Rel 6.0 for the NRS for this as there will be huge delay and the project delayed. This site's SS will be made a Failsafe NRS but still being the Main Office. Can this be achieved?)

Remote Site B (Rel 3.0) --> Upgrading to Rls 6, designate this site as Alternate NRS
(We will be making this SS the Primary NRS with the endpoints/routing entries which is a copy of Site A's NRS.

Do you think the other remote sites C,D,E & F Branch Office's phones will register to this Primary NRS and then redirect to Site A's system?

This Site B also has a second SS as a Follower SS which I am thinking to make it an Alternate NRS, as according to the NTPs the Primary NRS and Alternate NRS must be of the same software version)

Remote Site C (Rel 4.5) --> Failsafe NRS

Remote Site D (Rel 4.5) --> Failsafe NRS

Remote Site E (Rel 4.5) --> Failsafe NRS

Remote Site F (Rel 4.5) --> Failsafe NRS


So, do you think the above is achieveable?

 

[allenmac]

The phones do not register to the NRS, phones register to signaling servers/media cards running LTPS.

If you don't want to add a standalone sig server, continue with your current plan to keep the project on time, then evaluate later.

NRS can only run on a leader sig server, so you cannot make the follower sig server at site B Alternate NRS (or Failsafe NRS)

 

[ktse1210]

Hi allenmac,
Sorry. My typo. I do know that the phones register to the SS of it's own branch office (the phones's S1 should be pointing to it's own site's node).
What I mean was the redirection portion to the Main Site (Site A). This redirection is done by the NRS's SIP Redirect Server, right?

This is going to be crazy as on that cutover night, I will be migrating the entire system from H.323 to purely SIP Trunks. Bad move? Yes! BUT no choice. :-(

 

[allenmac]

I don't think the redirection is handled by the SIP redirect server. It is my understanding that the SIP redirect server and SIP proxy servers are only involved with actual call signaling.

You should be fine.

 

[ktse1210]

Hi Allenmac,
I got home about 3am in the morning after travelling back from site but it's all good. I managed to get the SIP Trunking tested out between 3x sites.

I went ahead to delete the H323 trunks off Site C and replace them with only SIP trunks. So here goes the test:

1) Test 1: Site C's system (SIP Only) --> via the NRS in Site A --> Site A's system (H323 and SIP) and vice versa = OK

2) Test 2: Site C's system (SIP Only) --> via the NRS in Site A --> Site B's system (H323 only) and vice versa = OK

I wanted to let Site C's system be connected on only SIP virtual trunking but before I left site, I noticed the Site C's IP phone has auto-reverted back to Local Mode and was unable to redirect.
Then I checked and there is no patches/deplist installed at all on the COTS SS. I guess I gotta go about installing the patch later on.
Anyway, I deleted the SIP trunks and re-config the Site C's system with H323 trunks again and this time, the IP phone redirected successfully. Something weird eh???

Oh yea, I've just got another question but I think will open a new thread for it.