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??

 

[allenmac]

To answer your questions:

1. Yes. I currently have about a dozen sites networked running various released from 4.5 to 5.5, with 3 sites H.323 Only, 1 Site H.323 and SIP, and the rest SIP only. All sites can call every other site.

2. You should already have NRS configured. You need to have both Site A and Site B in the same CDP Domain. Once both sites are registered to the NRS, and your routing entries are in place for both sites, then it is just a matter of configuring your call routing in the PBX's.

In site A you send all of the calls out over your SIP route - that's the only one you have.

In site B you need to know what type of virtual trunks the remote site has, and send the call out the same type of trunk.

If you every add another remote site (C) with H.323, then for site A to call site C, you need to define site B with a default route for CDP calls in your CDP domain. That way, the call signaling will be SIP from Site A to Site B, then H.323 from Site B to Site C.

 

[ktse1210]

Hi allenmac,
Thanks for the info.

The NRS is already running on the SS of Site B's system. So, all I need to do is to add the endpoint name which is the hostname of the SS of Site A's system, right?

E.g. Site B's hostname/endpoint name: "sssiteb" and Site A's hostname/endpoint "sssitea"

After that, in the NRS add the DN prefix of Site B's phones to the main endpoint sssitea's table with a route cost of 1.
Next, I will add in the Site B's DN prefix of its phones in its own endpoint with a route cost of 2.
Am I on the right track or totally off?

Do you have a snapshot of your NRS routing table?
Your help is much appreciated.
Cheers!

 

[ktse1210]

Erm...knock knock? Anyone? Help??

 

[Reusser]

your on the right track - did you do all you mentioned above? Did you save and commit? di your site register?

 

[allenmac]

Setting up standalone systems in NRS is a little different that configuring branch offices.

For each standalone system, the NRS should have a routing entry for that sites DN's associated with that site's endpoint with a cost of 1.

As far as endpoint names, they can be whatever you want them to be, and there is no requirement for them to be the same as the hostname of the sig server, or media card. They just have to be spelled the same on both ends.

For instance, we have a server naming convention that specifies 2 letters for the office location (like NY for New York City), V for voice equipment, followed by a number. This means my leader signaling server in New York City would have a host name like NYV23. This site runs H.323 trunks, so my H.323 endpoint name is NewYorkCS1000E, and as long as I define that in my node properties, and in the endpoint definition, everything is good.

 

[ktse1210]

Thanks Reusser. I will be proceeding to site later in the afternoon. Fingers and toes crossed.

 

[ktse1210]

Hi Allenmac,
So for Branch Office setup, in the NRS it will be something like:
Endpoint: sssitea
Has the DNs of all sites listed in it's table with the route cost of 1
WHILE
Endpoint: sssiteb
Has it's own DN listed in it's table with the route cost of 2.
Am I right to say that?


So in this case of standalone systems,
Endpoint: sssitea
Has it's own DNs listed in it's table with the route cost of 1
WHILE
Endpoint: sssiteb
Also Has it's own DN listed in it's table with the route cost of 1.

Is this hitting the right note?


Oh yea, one more thing. What did you set your SIP Support to in the NRS for the Main Site and the Remote Standalone site?
Is it Static SIP endpoint or Dynamic SIP endpoint?

Thanks and much appreciated.

 

[ktse1210]

Can anyone double confirm with me on my last statement please?
A final round before I head off into the horizon.

Thanks.

 

[KiwiOz07]

The following is correct:
In this case of standalone systems,
Endpoint: sssitea
Has it's own DNs listed in it's table with the route cost of 1
WHILE
Endpoint: sssiteb
Also Has it's own DN listed in it's table with the route cost of 1.

I have both all my sites set as Static SIP endpoints.

Hope that helps.

 

[allenmac]

You are correct.

Although in the branch office setup, I'm not sure you would ever need the entries with cost 2, because if the phones are registered locally, that indicates the endpoint is not registered, so there is no network connectivity to that site.

If the remote site had local trunking and local DID's, then I would use alternate routing and digit manipulation to re-route internal calls to those stations over the PSTN from the calling site (LD 86).

 

[ktse1210]

Thanks to both KiwiOz07 and allenmac for your input.

I actually tried these:

Setting 1:
Site A's has H323 RAS Endpoint and Static SIP Endpoint (TCP)
Site B has Dynamic SIP Endpoint (TCP)

Setting 2:
Site A's has H323 RAS Endpoint and Dynamic SIP Endpoint (UDP)
Site B has Dynamic SIP Endpoint (UDP)

Though I have not tried both Site A and Site B to be on Static SIP yet...well due to time constraints as its was already 1am.


Anyway, what settings 1 or 2....From the NRS's Gateway Endpoints information as the bottom, I can see Site B has successfully registered its SIP endpoint to the NRS but for Site A, it only has H323 successfully registerd in the NRS but NOT SIP.

From CS's D-Channel monitoring, when I use Site A's IP phone to call Site B, I can't see anything come up and the call drops (and displayed on the phone is "Release and Try Again").
I know in the CDP-DSC, I ensured when calling the Site B's extensions, the Site A's IP phone will seize the SIP Trunks.


Anyone has any more ideas?

 

[allenmac]

Personally I would use #2, as I have had problems with TCP message fragmentation causing issues with the SIP signaling.

You will need to have site A register as both H.323 and SIP for your SIP calls to work properly.

Are both SIP and H.323 enabled on the site A signaling servers?

 

[Reusser]

Agree with Allenmac - problem is probably in Site A Sigserver config setting.

Make sure SIP GW Settings are the same as on Site B
Make sure SIP URL map is the same as on Site B
Make sure enable IP Peer gateway is set to H323 and SIP
Make sure enable SIP proxy /redirect server is checked
Make sure SIP Domain name is the same
Make Sure the SIP gateway endpoint name is same as H323 ID
Make sure if you have SIP Authentication turned on (recomended) you have a the same password defined in both sig server and endpoint setup
Make sure enable gatekeeper is checked and role is selected (if NRS is Site B, site A should be either alternate or failsafe)
Make sure you also have TCP selected in SIP GW settings
in NRS endpoint setup do you have dynamip sip and Authentication and password entered if supports registration checked in SIP GW settings.

 

[BrokenRecord2]

I agree with Reusser. I find most of the time when I set this up and it doesn't work its usually something is not spelled correctly or not the same on both ends.

What kind of errors are you getting from the signaling servers? If you telnet into the Sig Server and look at the error codes it will usually point you in the right direction.

 

[ktse1210]

Hi guys,

Answer to Allenmac, yes both H.323 and SIP are enabled on Site A's Leader and Follower SS. The SIP settings are the same between Site A and B and the NRS.


I will be back on site tomorrow (sigh...as this site is about 1.5hrs drive away). Though I have double checked all the config that Reusser has stated but I will be triple checking it all again.

Anyway, it must be my brains that are not functioning due to the wee hours, I forgot to check the most important portion of it, the Voice Codecs. It slipped my mind to check and sure that both the G.711 and especially G.729 is the same on both systems.

As for nothing coming up on the D-Channel monitoring when I seize the SIP trunks, I reckon I better check the FRL in the RDB of that SIP route.

So far, on the SS....I am not getting any errors though. However, earlier I had a repetitive error due to the fact I have not configured Site B's endpoint on the NRS. Once I have done that, the errors have gone.

Thanks for your support guys.

 

[ktse1210]

Hi guys,
Amidst the challenge of getting SIP trunking to work, I forgot a very fundamental issue which is.....
Will a CS1000E Rel 6.0 (Site B) work with the NRS on an older version which in this case is the Meridian Option 81c's Rel 4.5 (Site A)?
Yes, the NRS is on the system which is software Rel 4.5 and the Rel 6.0 system is meant to register its endpoint to it.

One thing for sure is that the Rel 6.0 system seems to register it's endpoint successfully to the Rel 4.5 NRS...HOWEVER, my SIP calls between the sites are not working.
Let's say I am using Site A's Rel 4.5 IP phone to call Site B and from the Sig Server's screen capture, this appears:

27/11/2009 13:24:42 LOG0003 VTRK: itgMsgSend to task 0xf800
27/11/2009 13:24:42 LOG0003 VTRK: igcc: IgccToNpm: failed to send message to NPM
27/11/2009 13:24:42 LOG0003 VTRK: itgMsgSend to task 0xf800
27/11/2009 13:24:42 LOG0004 VTRK: Vtrk ACP Msg failed to send (0x12c)
27/11/2009 13:24:59 LOG0003 VTRK: itgMsgSend to task 0xf800
27/11/2009 13:24:59 LOG0003 VTRK: igcc: IgccToNpm: failed to send message to NPM
27/11/2009 13:25:03 LOG0003 VTRK: itgMsgSend to task 0xf800
27/11/2009 13:25:03 LOG0003 VTRK: igcc: IgccToNpm: failed to send message to NPM



THE NEXT CAPTURE:

27/11/2009 14:34:17 LOG0006 VTRK: vtrkA07MsgDispatcher: Current vtrk status is S
S Pending for TN 0x6bc3 chid 96
27/11/2009 14:34:17 LOG0003 VTRK: itgMsgSend to task 0xf800
27/11/2009 14:34:17 LOG0003 VTRK: igcc: sendEmptyReleaseCompToNpm: failure to se
nd msg to NPM
27/11/2009 14:34:17 LOG0006 VTRK: vtrkA07MsgDispatcher: Current vtrk status is S
S Pending for TN 0x6a07 chid 100
27/11/2009 14:34:17 LOG0003 VTRK: itgMsgSend to task 0xf800
27/11/2009 14:34:17 LOG0003 VTRK: igcc: sendEmptyReleaseCompToNpm: failure to se
nd msg to NPM



Here is my DCH Monitoring Capture:


-----This a test from Site A to Site B------

I am dialling 1021 (SIP Route ACOD) + 8600 (Ext No.):


FEAT :NAS
FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:3417 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)
CALLED #:8601 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)

DCH 2 IMSG CALLPROC REF 000001E4 CH 104 1 1 3 TOD 16:45:51

DCH 2 OMSG DISC REF 000001E4 CH 104 1 1 3 TOD 16:46:09
CAUSE :NORMAL CALL CLEARING ---> (this is where I terminate the call because I am getting silence over the phone)



I am dialling again for the second time:

DCH 2 OMSG SETUP REF 000001E4 CH 104 1 1 3 TOD 16:55:13
FEAT :NAS
FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:3417 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)
CALLED #:8601 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)

DCH 2 IMSG CALLPROC REF 000001E4 CH 104 1 1 3 TOD 16:55:13

DCH 2 OMSG DISC REF 000001E4 CH 104 1 1 3 TOD 16:55:43
CAUSE :NORMAL CALL CLEARING

DCH 2 OMSG RELEASE REF 000001E4 CH 104 1 1 3 TOD 16:55:47
CAUSE :RECOVERY ON TIMER EXPIRY

DCH 2 IMSG REL COMP REF 000001E4 CH 104 1 1 3 TOD 16:55:47



----This a test from Site B to Site A------

I am dialling 1003 (SIP Route ACOD) + 3417 (Ext No.):


DCH 64 OMSG SETUP REF 000001F8 CH 108 0 3 23 TOD 16:48:55
FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:8601 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)
CALLED #:3417 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)

DCH 64 IMSG CALLPROC REF 000001F8 CH 108 0 3 23 TOD 16:48:55

DCH 64 IMSG DISC REF 000001F8 CH 108 0 3 23 TOD 16:48:55
CAUSE :UNASSIGNED NUMBER

DCH 64 OMSG RELEASE REF 000001F8 CH 108 0 3 23 TOD 16:48:55

DCH 64 IMSG REL COMP REF 000001F8 CH 108 0 3 23 TOD 16:48:55



I am dialling 1003 (SIP Route ACOD) + 2913 (Ext No.):


DCH 64 OMSG SETUP REF 000001F8 CH 108 0 3 23 TOD 16:50:11
FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:8601 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)
CALLED #:2913 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)

DCH 64 IMSG CALLPROC REF 000001F8 CH 108 0 3 23 TOD 16:50:11

DCH 64 IMSG DISC REF 000001F8 CH 108 0 3 23 TOD 16:50:11
CAUSE :UNASSIGNED NUMBER

DCH 64 OMSG RELEASE REF 000001F8 CH 108 0 3 23 TOD 16:50:11

DCH 64 IMSG REL COMP REF 000001F8 CH 108 0 3 23 TOD 16:50:11



I am dialling directly Ext 2913 without the SIP route ACOD:

FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:8601 NUM PLAN: PRIVATE/ABBREVIATED (CDP)
CALLED #:2913 NUM PLAN: PRIVATE/ABBREVIATED (CDP)

DCH 64 IMSG CALLPROC REF 000001F8 CH 108 0 3 23 TOD 16:50:41

DCH 64 IMSG DISC REF 000001F8 CH 108 0 3 23 TOD 16:50:47
CAUSE ESTINATION IS OUT OF SERVICE

DCH 64 OMSG RELEASE REF 000001F8 CH 108 0 3 23 TOD 16:50:47

DCH 64 IMSG REL COMP REF 000001F8 CH 108 0 3 23 TOD 16:50:47



I am dialling Ext 3417 directly without the SIP Route ACOD:

DCH 64 OMSG SETUP REF 000001F8 CH 108 0 3 23 TOD 16:51:55
FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:8601 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)
CALLED #:3417 NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)

DCH 64 IMSG CALLPROC REF 000001F8 CH 108 0 3 23 TOD 16:51:55

DCH 64 IMSG DISC REF 000001F8 CH 108 0 3 23 TOD 16:51:55
CAUSE :UNASSIGNED NUMBER

DCH 64 OMSG RELEASE REF 000001F8 CH 108 0 3 23 TOD 16:51:55

DCH 64 IMSG REL COMP REF 000001F8 CH 108 0 3 23 TOD 16:51:55



SIGHHHHH....time is running short and the new system cutover is going to be next week and looking at this issue, the project might have to be delayed till this is sorted out. :-(
Help!!!!! Anyone???????

 

[allenmac]

I am confused by the top of your last post. You said your 6.0 endpoint is registering to your 4.5 NRS?

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.

In an environment with mixed release switches, it is much easier to manage the NRS if it is running in Standalone mode. This way if you are going to upgrade a switch to a higher release, you simply upgrade the NRS first.

 

[KiwiOz07]

Agree with allenmac. The NRS needs to be running Rls 6.

 

[ktse1210]

Hi allenmac,

Yes, as the Rel 6.0 system is the latest system upgrade to a Site B's original Rel 3.0 system.

To give you a brief rundown on this network layout, in the current plan there are 6x sites.
Main Site A (Rel 4.5)
Remote Site B (Rel 3.0) ----> This will be upgraded to Rel 6.0
Remote Site C (Rel 4.5)
Remote Site D (Rel 4.5)
Remote Site E (Rel 4.5)
Remote Site F (Rel 4.5)

Site A is where the NRS is and the rest of the other sites are registered to it. Sites C to F are Branch Offices whre their NRS's are set as Failsafe NRSs to the Primary NRS.

Now, the plan is to upgrade Site B to Rel 6.0. Then get it to register it's endpoint to the Site A's Rel 4.5 NRS using SIP.

Do correct me if I am wrong, but if Site B's Rel 6.0 is a standalone system, it still gotta have an NRS right? In it's NRS setting, I am pointing it's Primary TLAN to Site A's NRS (planning to make the Rel 6.0 a failsafe NRS).

I checked Site A's NRS, the Gateway Endpoint table shows that Site B's Rel 6.0 system has successfully registered to the Site A's NRS.


Can you explain this portion of your statement please --->

"In an environment with mixed release switches, it is much easier to manage the NRS if it is running in Standalone mode."

What do you mean by standalone mode?

Thanks for your patience in helping me on this.