SS7 Message

We recently established an Access Tandem we will call ULT. We are processing TRS calls between an SS7 Trunk Group from a customer who can manipulate the TNS field in the message to establish carrier of choice. When the call is sent to ULT it is being rejected for no circuit available. Decoding the message received form the customer we see all the correct features such as CIC and Network Circuit ID that the local provider is requesting.This is being presented in the 48th Octet. HOWEVER the Local provider of this AT is stating they are not receiving the Circuit ID. When we examine the ISUP message we only see half of the message. I believe that this is caused by the call Originating and Terminating to the same OPC. Does anyone have an opinion on any of this? We are "sending" the appropriate OZZ/Circuit ID. Do we need to reserve? Calls terminating into the same switch and TF calls work just fine.

Reply to
Scott
Loading thread data ...

Gees! What an alphabet soup message! (And no offense meant, Scott) Remember when you could be successful in the telephone business if you knew Battery, Ground & Payday?

Reply to
Al Gillis

Confirm that all trunks are idle. Run trunk query on the group.

Why are you only seeing half of the message? And what message? The Release? The IAM?

Exactly what type of call are you making that originates and terminates to the same OPC? A test call? Should the AT be routing the call right back to you? And what do you mean by "reserve"?

What you need to do is monitor the call in both directions, trap the messages and post them here. Of course if you have fixed your problem, posting the resolution could be educational.....

Ray

Reply to
rayj00

After investigating this further we have discovered both parts of the IAM message. The TNS field is being presented as an Optional PArameter. Basically what we need is a way to get the DMS 250 to present the TNS

250 as an actual parameter. Currently only the CIP field is going across. I cannot put eh screen prints of the traps in here
Reply to
Scott

Well, the TNS parameter is an optional parameter and the fact that it is optional should not cause problems in the AT. I thought the AT is the

250? Your end office should be presenting the IAM to the AT.

You should see the Carrier Code and the Circuit Identification Code in the TNS parameter. (0ZZ / 1N/N'X in the MF world). Are these values correct? Actually, confirm that all fields of the TNS parameter are correct and get back to us...

Ray

Reply to
rayj00

An "actual parameter"? I think you're confused. There are three kinds of parameters in the ISUP I learned (mind you, this is a little rusty, but not *that* rusty): Mandatory fixed-length, mandatory variable-length, and optional. Which parameters are mandatory and which are optional on each message is specified by the standard; an implementation that let you change which kind of parameter was which would be broken: it wouldn't interoperate.

I'm not sure what's causing the problem you see, but I'm pretty sure it isn't what you think it is.

Reply to
Thor Lancelot Simon

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.