Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

OS4000 to Cisco UCM 1

Status
Not open for further replies.

TipandRingtoSIP

Technical User
Apr 5, 2016
115
US
Going to be configuring SIP tie trunks to a Cisco and was reading earlier posts about using the SIP trunk profiles in the STMI rather than GKREG.. So I have a question about a message that displays in the WBM when I click on the Cisco UCM profile. I see in red letters at the top "PROJECT SPECIFIC RELEASE authorisation is required from Product Management to use this trunk profile! " So does Unify have this profile locked or something that needs licensing ?????
 
Our SMTI to CUCM uses NatTrkWithoutRegistration
Make sure you turn off Clear Channel Codec, otherwise you won't get any audio.
 
I am going to be utilizing an existing STMI that is currently configured for Cornet SIPq - If I use a SIP trunk profile in WBM, does that do away with the GKREG?? Just thinking I use GKREG to setup my LDPLN , LDAT, etc... If GKREG is no longer used, how do you point the call route to the gateway??

Many thanks!
 
Nevermind, I just remembered the destination Gateway is the one that the call routes point to... Not the gateway in my switch....
 
The profile is not locked, it's just that if you wanted support on it, the install had to be authorised by Product Management. That warning is not in the newer loadwares anyway, that is no longer a requirement for connection to Cisco. So you are free to use it, it will function fine. You should use the CUCM profile because that it was what was tested with Cisco, not nattrkwithoutreg. I don't know what the difference is and can't be bothered to look. Either will work with basic call, but the point is, after test, the CUCM profile was created for connection to Cisco, so there is no reason to not use it.

For a native SIP connection like this, you don't use GKREG (anymore). In the CUCM GUI profile, configure in the "Proxy" parameter the Cisco IP, port you can leave empty if it's 5060 (or put it in, it doesn't matter), make sure UDP/TCP is correct, and that's it. Outbound proxy, inbound proxy, you can leave blank. You only need an entry in proxy. In the LDAT for the outgoing call, you don't need to put any gateway references in from GKREG (in fact, make sure you don't), and it'll just invite to the proxy IP.
 
Thank You Moriendi,
That almost sounds too easy...

So I would set the extension range in dial plan (WABE, I know, I can't stop calling it dial plan) to a DAR of TIE and then create the LDP to point to the route and the route just points to the trunk group??

Since these are currently SIPQ, when I delete the GKREG entry, will the SIP Trunk Profile take care of overwriting this?

Thanks again, this is really helpful.
 
If you're going to use the same config mostly as the SIP-Q circuit, yes point to the TDCSU in the usual way with RICHT and LDAT. In GKREG it will have an internal (INTGW) entry, change that from SIPQ to SIP. In CGWB (GLOBIF) change the number of channels in SIPQ to 0, and whatever number of channels you want in SIP, and restart the card. Configure the profile/proxy etc, and that should be it. If it doesn't work you can browse to the card GUI, Maintenance, and enable the RPCAP daemon. In Wireshark you can Manage Interfaces, add a remote interface (the card IP), and then you can stream the signalling straight to Wireshark, see what's going on. If there's no invite at all, you'd need to trace the 4K side and check your routing.

You don't need that internal GKREG entry but once it's there, like it is now, just change it so it is correct (SIP). If you were adding from nothing, you wouldn't need to add it. But now the LEGKDATA is added in CGWB, it probably won't let you delete it. Might have to strip the whole lot out and put it back in without, not really worth it. Try it, all it can do is say no.
 
I'll give it a go.. Mostly same config, but new trunk group, new extension range in WABE. The existing numbers to the other 4K which is remaining, have a DAR of STN and point directly to the DEST NO.... I'm pulling this STMI from the trunk group and creating a new group for Cisco. Should I not use the SIP Trunk Profile in the gui? Or should I flag the trunk profile and then also make adjustments in GKREG and CGWB?
Thanks again!!
 
Don't get confused with the GKREG.

There are two type of entry in the DIS-GKREG output, internal and external. Having an INTGW entry assigned (LEGK data for the board CGWB is filled in, GWNO and GWDIRNO match to an INTGW entry in GKREG) is not the same thing as "using GKREG" to dial out. If the STMI has had some historic configuration on it, was configured years ago, or it has been used for SIP-Q, it will have that entry, and will definitely have been using GKREG EXTGW GWNO's to dial out as well. But having a configured GKREG INTGW does not mean you have to use GKREG to dial out.

Dialling out using GKREG means that a profile is not configured on the board, and in the LDAT for the outgoing route you have at least one of the GKREG EXTGW GWNOs configured (GW1 etc in the LDAT). When the call is made to the board, 4K passes the IP of the referenced EXTGW in the setup message, and the board knows where to send the packets.

Dialling out without GKREG means no GWNO is passed in the LDAT, and a profile is activated on the board. The profile contains the IP address (the proxy) so the board knows where to send packets. There are also other SIP configuration parameters in the profile that CGWB knows nothing about, payload type for tones, various SIP signalling options that might be needed that were discovered during test. You don't have those configuration options if you don't use a profile. You also have the security of making sure the board will only handle incoming traffic from the specified proxy IP once the profile is active. It doesn't matter for this scenario if the board has an INTGW configured or not. You might have one due to some historical config, but it doesn't need it. If it is there in GKREG though, I would make sure it is correct for SIP-Q/SIP because having it wrong is likely to cause an issue somewhere.

So if this board was used for SIP-Q you will have an INTGW configured with a GWNO, GWDIRNO that matches CGWB LEGK. That's fine, leave them, you still use the profile to dial out and you don't specify the GW1, GW2 etc in the LDAT. You can't remove it anyway without deleting the board and adding again, and it's not worth the hassle.

Latest loadwares actually specify that for native SIP the profile use is mandatory, it should be deactivated only for lab purposes (you specify whether to use the profile or not in the GUI).

My native SIP trunk here looks like this in CGWB

LEGK DATA
------------------
GWNO = (0)
GWDIRNO =
REGEXTGK = NO (NO)


No reference to GKREG at all. Yours will have something in but it doesn't matter. You still activate the profile.

I assume you still have another STMI in this trunk group that was using SIP-Q. If not, you will have to delete the LCR pointing to the old SIP-Q before it lets you delete/change that trunk group.

It is possible to use a profile for SIP-Q if you want, but you don't need to unless you want to use DNS SRV, because you can put a DNS name in the GUI but you can't put it in GKREG.

Don't forget to change the channels from SIP-Q to SIP in CGWB.
 
Great Info, Thank you!
Yes, I still have 3 other STMI's in the trunk group (this side was way over trunked ) so my plan is to delete the TDCSU and then create the new Trunk group, then add the new TDCSU...

I think I have a good handle on this thanks to your help...

 
Worked like a charm... Except that when I deleted the TDCSU from the Cornet Trunk group and re-assigned to my new Cisco trunk group, my Cornet calls started failing... I discovered separate LDPLN entries that had routes for each STMI in the trunk group??? There were LDPLN entries for the GWDIRNO's.. I was not aware of those... Whoops! Working now tough...
Thanks so much for your help!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top