406 -> IP -> 406 -> PRI Caller ID

[parnellij]

I have a "remote" 406 with an IP line connected to our "main" 406 which in turn is connected to a PRI. Voice networking is enabled on the IP line. For incoming call routes on the "main" 406, I've typed (can't select) the extensions on the "remote" 406, and all seems well (incoming caller ID works well). Outgoing calls from the "remote" 406 are set up with short codes like [9]1xxxxxxxxxx Dial3K1 91N to the line group containing the IP line to the "main" 406 which in turn matches the number to it's own short code [9]1xxxxxxxxxx Dial 1N to the PRI line. I was hoping that the "main" 406 would match up the extensions from the "remote" 406 to the incoming call route and correctly provide the outgoing caller ID, but that doesn't seem to be the case (it actually grabs the number from an incoming call route that has a blank destination). For testing, I added SS to the short codes on the "main" 406, and the extension numbers from the "remote" 406 are actually sent over the PRI. This proves to me that the "main" 406 is at least aware of the source extension numbers from the "remote" 406 during outbound calls, but there is no mapping back to the incoming call route number. Am I going about this all wrong?

 

[kholladay]

Put the incoming call routes in the remote. Even though they are not used for the IP trunk they should be used for outbound calls.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[parnellij]

kholladay,

Thanks for the response. I had already tried this as well. No go.

 

[CarGoSki]

Perhaps I read wrong but you are trying to send different ID from the remote scn than is being sent from the main?

 

[parnellij]

To simplify the question, how can I trigger the main 406 to match the extension to the incoming call route number when the extension is on another 406 connected via IP line?

The "remote" 406 is a new addition to our system and the problem was unexpected because the outgoing caller ID has always just worked on the original system. We have a block of DID's and an incoming call route entry for each DID to an extension. My understanding is the system just uses the incoming call route entry in reverse to supply the caller ID number on outbound calls. With the additional system, the inbound calls still originate from the PRI connected to the main system, I add incoming call routes for each extension, and the SCN seems to figure it out from there. On outbound calls originating from the remote 406, the main system doesn't seem to use the same caller ID trick it does with it's own extensions.

 

[amriddle01]

Have you tried using User shortcodes on the remote site to send the caller id?

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[parnellij]

amriddle01,

Thanks for the response. I was leaving that option as a last resort knowing how messy that could get, but that's what I'll end up doing if there isn't a cleaner way.

 

[Westi]

you could have a system shortcode in the remote system
9N
81N (81 N to have it register in the main system as not 9)
line group ID of the IP line

in the main system you make a new ARS table and shortcode to send it to the ARS
81N
N
new ARS

in the ARS you make the shortcode
N
NsxxxxxE
line group

this should send the number you send with the Extension behind to send your DID
All theoretically though.

Joe W.

FHandw., ACS

If you can't be good, be good at it!

 

[parnellij]

Westi,

Thanks for the response. That's pretty clever and would be much neater than user short codes. Big problem though. We have 2 DID blocks (it's always something, isn't it?). The other thing I noticed when I originally created a special short code on the main unit for outbound calls originating from the remote unit is that the translated short code was displayed on the phone. Ugly!

Last thing, I just realized I can't use user short codes because the S is ignored by the main unit. Dang!!

Maybe I'll just substitute our main line number for all outgoing calls originating from the remote unit and be done with it.

Thanks all for your help (unless anyone else wants to take a crack at it )

 

[Westi]

I guess you send 9 and the number with the sxxxx to show the number outgoing. Try with my shortcodes because 9 in the main site will result in the local shortcode being used. I know we use the main numbers not the DID to make this work and make phone calls from different sites with the local caller ID and it works. Maybe I can ask my customer that uses this solution if I can screw around in their system (I doubt that they are willing to test it for me)and then I let you know

Joe W.

FHandw., ACS

If you can't be good, be good at it!

 

[janni78]

Have you looked in a trace what's actually sent out on the PRI line?

It should send something as a CLI, and then it's up to the provider if they use it or ignore it.

"Trying is the first step to failure..." - Homer

 

[parnellij]

Westi,

I'll try your suggestion and let you know what happens. You don't need to bug your customer (unless you're satisfying your own curiosity). I'm usually at the office an hour past everyone else and the remote site is a couple of weeks from being occupied.

 

[parnellij]

janni78,

I haven't had the need to do a trace because the main unit has always sent something I recognized as a DID. If I withhold the caller ID, our billing number is sent by the provider, which hasn't happened in any of my tests.

 

[janni78]

Maybe I'm just confused, but if you make a ISDN trace on the main site when making an external call from the remote site you'll see what's sent to the provider for that call.

Also I don't see why you use Dial3k1 on your remote site shortcode, I only use Dial, but it might end up being the same in the end.

"Trying is the first step to failure..." - Homer