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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CLID for GSM Network

Status
Not open for further replies.

jjfuertesrico

IS-IT--Management
Oct 27, 2005
11
0
0
DE
Hi,

my GSM supplier offered me to link my PBX with its GSM network through a T1 PRI link. They required me to identify the CLID as 5xxxx where xxxx is the internal extension number. In the other hand they cannot help me on how to configure my Nortel M11.

My current configuration is the following:
1 PRI for local/national calls (requires CLID in the form nnnnnxxxx where xxxx is the extension and nnnnn the common numbers for all of us).
1 PRI for international calls (CLID not required)
1 ITG trunk

1 PRI for GSM Network

My problem is that on the new PRI for GSM, I'm still sending the full nnnnnxxxx number. I tried it creating an LSC prefix (5) on the CLID table, but at the other sides of the ITG, the number calling is 5xxxx, but on the GSM Network still the full nnnnnxxxx.

I saw a thread about CLID per route, it's what I'm looking for, but it seems is not possible.

If anybody can help me will be appreciated and, of course, if need more information.

Regards,
Julián.
 
your trying to send a clid or a calling number? the id does not have to match and the post is right. you can't send clid 0 to route one and clid table 1 to route 2.. clid is tied to the dn or the set.. i can send the clid table tied to key 0 or i can send a unique clid per line, or for that matter a bogas number. but i have to send that to all routes. i had a simular problem with a paraphonics ivr. since it only had 1 line side interface i built a work around (thank;s to danny L) two pris back to back. sent all calls for the ive to a dsc, that hits the outbound pri of the back to back, the inbound side of the back to back changed all inbound to the same dn, with auto yes and atdn xxxxx the number the ivr needed... xxxxxx was the hunt group pilot on the 24 numbers of the line side... so the ivr saw only what i told it, not the dialed dn and not the calling numbers, it collected it's data sent the call the symposium, sent the get file to the sql, we have screen pop, the world kept turning..

john poole
bellsouth business
columbia,sc
 
John,

I thought that Calling number was the same than CLID. Probably I missunderstood it.

The solution with two PRIs is very nice but little expensive.

I am thinking to use an UDP number built on (HLOC + DN) -I saw on the manual-, but I don't know which LD is the one to create UDPs.

To ilustrate my problem, this is a trace of the D-channel that connects to the GSM network with a call made from my extension (7833):
DCH 11 UIPE_OMSG CC_SETUP_REQ REF 00000120 CH 1 13 TOD 17:41:12
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:913097833 NUM PLAN: E164 TON: NATL
CALLED #:25555 NUM PLAN: E164 TON: UNKNOWN

GSM network needs a line like:
CALLING #:57833 NUM PLAN: E164 TON: UNKNOWN

But I don't want to loose the original data for calls to the fixed network.

In any case, thanks for your info.

Regards,
Julián.
 
John,

I found the solution.

On the RDB I changed the RCLS from EXT to INT; Changed the ISDN CPFXS from NO to YES and then I inserted the HNTN with my "GSM" preffix, 5.

In this way, I'm sending the calls to the supplier in the correct way.

DCH 11 UIPE_OMSG CC_SETUP_REQ REF 0000012E CH 1 29 TOD 16:43:30
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:57833 NUM PLAN: E164 TON: UNKNOWN
CALLED #:26985 NUM PLAN: E164 TON: UNKNOWN

But, if a colleague at another location connected through VoIP (ITG) tries to dial a GSM, the calling number changes from UNKNOWN to NATL.

DCH 11 UIPE_OMSG CC_SETUP_REQ REF 0000012E CH 1 29 TOD 16:43:30
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:57833 NUM PLAN: E164 TON: NATL
CALLED #:26985 NUM PLAN: E164 TON: UNKNOWN

On both ITG trunks CTYP is set as UNKNOWN. Incoming DCH message certifies it.

Any ideas? Who is changing the type of call?

Julián
 
thanks for the update, i should have caught that, i've been burned by ext route def before.. another thing that gives you better control is to define the pni and enter it into the cdb... i'll save that post because it will come back up..

john poole
bellsouth business
columbia,sc
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top