VoIP trunks

[phoneguyv]

I just installed VoIP tie trunks between two sites. One is a 61C running Succ. 4 and the other an 11C with same software. Each site has signaling servers and VGMCs. We are using an extremely simple config. Only the two sites connected VoIP and primarily it's used to call extensions back and forth. That is working fine. I've defined each site's dialing plan in the NRS so they can call each other's extensions with 4-digit dialing. Dialed number and calling party names come accross just fine.

Site A has analog tie trunks to another network that has variable digit length dialing patterns. Typically what we do is dial an access code and once we get dailtone begin dialing the desired number. That's how the system worked from Site B when all they had was an OPX coming from Site A.

Now with these new trunks when I pass the access code along to Site A from Site B I get dailtone back but can not break it.

I realize there are different call types that need to be defined or identified but from my limited experience when you have the wrong call type usually the connection never progresses. In this case with me receiving the dial tone it would seem I'm beyond that point but I'm not experienced enough with these trunks to be sure.

I've been setting up the routing entries in the NRS a few different ways but either I end up with no dialtone coming back or with dialtone that I can't break. I recall from previous installs/upgrades that these entries were critical for trunk calls, dialing off a far end PBX, but again I'm accessing the trunk in this case.

I'm just not sure if it's an issue on Site B, with the trunks themselves or with Site A. Any suggestions will be greatly appreciated.

If it is important we're only using H.323 gatekeeper (not SIP).

Thanks in advance,

V

 

[lretrievers]

Are you sending trunk access codes? I believe you want to be sending ESN AC1 or AC2 access code instead; when it gets to the other side, it needs to access their BARS.

 

[dlesap]

I suggest to create a TSC from remote site. That TSC have to be defined in NRS going to Main site. I guess that entry have to be defined as CDP dialing plan in NRS.

Monitor DCH in both sites to see where call fails. If DCH message is sending from Remote and not coming at Main, then NRS do leave the call goes through. If so, give the DCH trace to be able to give more help.
If DCH message comes at remote site but call fails, try to find trunk restrictions.

 

[phoneguyv]

Thanks for your replies. I'll include some printouts of traces.


First is a trace from within element manager at the Site A side.

TRAC - Trace calls for specified customer, route and member 0 5 1
-----------------------------------------------------------------
ACTIVE TN 024 0 02 00
ORIG 128 0 00 00 V PHYSICAL TN 008 0 00 26 IPTI RMBR 15 1
TERM 024 0 02 00 TIE RMBR 5 1
DIAL DN 87
MAIN_PM DIAL AUX_PM TEMPPATH
TALKSLOT ORIG 59 TERM 27 JUNCTOR ORIG0 TERM0
EES_DATA:
NONE
QUEU NONE
CALL ID 0 161
NETWORK CALL ID 0 659
---- ISDN ISL CALL (ORIG) ----
CALL REF # = 385
BEARER CAP = VOICE
HLC =
CALL STATE = 9 INCOMING
CALLING NO = 4444 NUM_PLANRIVATE TON:RESERVED ESN:LOC
CALLED NO = 87 NUM_PLANRIVATE TON:NETWORK SPECIFIC ESN:SPN


Next is a trace of calling TN (4444) on the Site B side.

.13:55:12 07/05/2006
TN 007 0 00 15
KEY 0 SCR MARP ACTIVE TN 007 0 00 15
ORIG 007 0 00 15 0 SCR MARP 0 4444 3904
TERM 061 0 00 31 V PHYSICAL TN 005 0 00 30 IPTI RMBR 7 32 TXTSAP: 33.128.17.20 PORT: 5252 CODEC: 4 H.323 ENDPOINT IP: 33.128.17.100
DIAL DN 4949
MAIN_PM DIAL AUX_PM COMPLETE
TALKSLOT ORIG 3 TERM 35
QUEU NONE
CALL ID 0 659


---- ISDN ISL CALL (TERM) ----
CALL REF # = 416
BEARER CAP = VOICE
HLC =
CALL STATE = 3 OUTGOING
CALLING NO = 4444 NUM_PLANRIVATE TON:RESERVED ESN:LOC
CALLED NO = 10587 NUM_PLANRIVATE TON:NETWORK SPECIFIC ESN:SPN


Site B DCH traffic

DCH 7 OMSG SETUP REF 000001A0 CH 61 0 0 31 TOD 13:58:40
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:4444 NUM PLAN: PRIVATE/RESERVED (LOC)
CALLED #:10587 NUM PLAN: PRIVATE/NETWORK SPECIFIC (SPN)

DCH 7 IMSG CALLPROC REF 000001A0 CH 61 0 0 31 TOD 13:58:42

DCH 7 IMSG PROGRESS REF 000001A0 CH 61 0 0 31 TOD 13:58:42
PROGRESS: CALL IS NOT END TO END ISDN

End of trace output

Note the originally dialed number, 4949, is a mod so as not to interfere with active users. I have been using TSC on Site B side as well as DSC. That number is immediately changed to 87, the ACOD of the tie route at the Site A side.

If you notice NUM PLAN is always {private something}. I think I need to work on that to get it public. My NRS skills aren't what they need to be. I have changed it to different settings, CDP (level1 regional, level0 regional)and as long as I get Side B to send something the NRS is expecting (meaning both SPN or CDP) it lets the call go through. Again, when I say go through I mean I get dialtone but can't break it.

I don't think getting into the E164 config settings will help in this case. It's most similar to special numbers, with no fixed length, but private special numbers isn't it.

We don't use overlap signaling due to our simple configs but in this case I may try it to see if that makes a difference.

I am also considering using AC2 to see if I can swing something that way. That's another thing we usually don't need. Perhaps AC2 followed by an SPN. I'll need to delete the SPN digit(s) as I only need access to the route's dialtone and don't want to pass any initial digits due to the delay. (satellite)

Thanks again for your time and thoughts,

V

 

[dlesap]

Is site B the originating site?
Please give only DCH trace for both Site A & B.

In NRS, did you give a name to Special in DomainL0 or DomainL1?

 

[phoneguyv]

You'll have to give me some time to get Site A's DCH trace. I've got to run to the other side. About an hour or two.

In the last hour or so I've added AC2. Tried the call with the same results. Added/turned on overlap signaling and still the same results. You may be right about something at the Site A end. I know the trunks have access because I built it all plus if they were blocking I wouldn't get dialtone. It's interesting and I'm learning a bit but I still need to get it working.

Thanks a lot for your assistance.

V

 

[phoneguyv]

I've just gotten to the Site A side and had someone make the same call from the Side B side and the results of the DCH traffic were identical. Every message was identical except when Site B said IMSG Site A said OMSG.

One other difference but this would be expected. Looking at the DCH output above, where it says:

CALLED #: 10587

the 105 was striped away for the Site A incoming message. Actually, the test call was made with the new AC2 and the initial numbers were 102.

OK, one more thing, channel numbers were different.

Time to start digging again.

Mark

 

[dlesap]

First, overlap signaling doesn't have to be on. DCH is speaking with SigServ, not with other side DCH, which is also speaking with its SS. This is the reason why channels are not the same.

Préfix 105 is added by calling site cause ESN5 is on in RDB configuration. That is used if you want the opposite site is doing call restriction. Other value is STD for SIGO prompt.

If i understand well, at site A you receive DCH message from remote site, meaning NRS is routing the call correctly. After dialing 87, is the call sent to NRS? If so, 10587 is the coming number at Site A and you expect continue dialing. Am i right?

Can't you change the TSC lenght to the full dialled number lenght? For example if you have to dial 871234, TSC FLEN have to be 6. Give a try

 

[phoneguyv]

dlesap,

Thanks for your time!

I understand the part about each DCH speaking to its own SS and the fact that the channel numbers represent each side's config. I just wanted to add every detail to head off anyone questioning why everything was the same. I simply meant information wise things were the same.

The 105/102 is also something I understand but added for clarification's sake.

I can't set an accurate FLEN because there are many different length dialing strings that are possible on this tie line. Some are 5 digit, some 10 digit and some require further access codes followed by pauses and additional digits. Also, if you do just pump digits right through after the access code more often then not a digit or two gets lost due to the delay. These are analog tie lines over a satellite. You must wait to hear the next dialtone before proceeding with more digits.

I simply want to access the tie line by dialing 2-digits. At Site A a caller dials 87, waits for dialtone and then continues dialing whatever they need. From Site B with the OPX they basically did the same thing. They had a steering code that seized the OPX and passed 87. From there they waited for the dialtone to come from the tie line, through Site A's PBX and over the OPX and then they could continue dialing.

Now with these VoIP lines something is preventing Site B from doing the same thing. If I use a simple steering code, DSC/TSC, and I set my call type in NRS correctly (meaning Level0 regional) I get dialtone that I can't break. The digits are certainly getting through the system(s) correctly but still no breaking dialtone.

Thanks for the advice on the overlap signaling. That's just a novice (to these VoIP trunks) person trying anything.

I really don't mind problems as they give you the ability to dig in and learn how things tick. I'm sure when I get this resolved, either on my own or with assistance, there will be a lot of good that came out of it. Had it all worked from the start I certainly wouldn't have added AC2 or the overlap signaling.

Again, thanks for your time and thoughts. I'll be working on this for at least a few more hours.

V

 

[dlesap]

Front digits 1xx represents NCOS travelling. 1 mean NCOS of the orginating site is sent through the trunk. The 2 following digits represent the NCOS value itself.

Using dialing through an open H323 channel required H245 tunneling to be open. Are you able to access a Voice Mail from remote and send digits to give ID and password? If no, that a normal fact that your additionnal digits are not accepted.

I have to see how H245 have to be set up. I guess it's in SS configuration, but i don't know where and how it's handle.

 

[dlesap]

H245 is active by default.
2 try you can do:

1- Check if G711 is used in the actice trunk
2- Try to dial from an analog set

and give a feedback

By tracing call on SS, you may see a "H245 UserInputIndication" when adding digits

 

[phoneguyv]

Yes I can send digits to CallPilot on the Site A PBX. Something along those lines was one of my first thoughts but it is possible.

For what it's worth, this reminds me of how sometimes when I forget to set MANO to yes while building a DID route for MIRAN, I can't enter DTMF tones. I dial into MIRAN using the ACOD but then can't log in. I setup MIRANs about 3 or 4 times a year and about half the time forget this and have to look in the book to see what it was I forgot. I tried that earlier with no luck.

Thanks again for your time,

V

 

[phoneguyv]

How do I check which CODEC is being used? I recall doing this last time I set one of these up, over a year ago, but can't recall. I've tried every trace I can find. I seem to recall I can look up what was used on the last call.

Great idea on the analog set! I tried it and still no breaking dialtone. So it isn't just that the M3904 isn't trying to send the digits but they are not being passed.

Thanks, this opens new areas to look into.

 

[phoneguyv]

Thanks for your time dlesap. I'm leaving until tomorrow when I'll try again. I'll have access tomorrow to some techs that have done this recently. Even if I don't hear from you I'll post how it all worked out.

V