SCN Twinning, Originating CLD Help 1

[element4749]

Morning all, hopefully someone can help guide me in the right direction here.

I have two sites SCN'ed together, 9.0. Our provider allows us to send any digits outbound. Site A calls Site B, Site B extension has mobile twinning enabled, originating calling ID from Site A extension to Site B's twinned cell phone only shows the first three digits of the area code of Site B's DID block, and not the originating calling ID from site A's extension.

I've tested passing numbers outside of the DID block at Site B and they pass through just fine, its just this particular circumstance.

I am only half way through my coffee here, so any help is appreciated.

Thank you,

 

[driven0]

Do you have "Use Internal Data" on the SIP URI? If so what do you have on the users SIP tab?

 

[element4749]

Appreciate the reply,

I am using H.323 IP trunks for inter-site SCN communication. This is actually happening will all sites now we just did not realize it.

What I think is happening is local extension at Site A is dialing local twinned extension at site B. When it sends originating calling ID, it would seem that it does not translate full 10 digits on egress of the PSTN and the carrier does not know what to do with it.

At site A and C the calling ID shows Unknown, at site B it just shows the area code.

Is there a way to translate calling ID for inter-site SCN communication?

Thanks all,

 

[driven0]

Do you have anything in your SIP URI ? Are you using wildcard (*) or Use Internal Data or a specific number?

If you could please capture a trace from site to site and post it here that would be helpful.

 

[element4749]

Maybe I am mixed up or just not understanding your question, I am not using SIP. Only H.323. So I don't have any SIP URI's or wildcards?

The knowledge base indicates that line short codes can be applied to any digits received with incoming calls (specific to H.323). I know that it matches based on extension first, and I don't have any short codes currently defined on my H.323 trunks. Since its just matching a remote extension in my SCN, do I need to define a full 10 digit number match?

Basically I am not familiar with the short code syntax for H.323 IP trunks. Not sure if I can do digit translations with it or not, or if I need to build generic 10 digit definitions.

I will try to get a trace when I can, I am not on site, so its hard to coordinate right now.

Maybe I should be using SIP instead of H.323?

Thanks for the input and assistance.

 

[driven0]

Sorry for the confusion.

Under Line --> SIP Line --> SIP URI do you have use internal data or something else? I'm asking about this because if you use internal data it will send out what is listed in the SIP tab under Users.

Shouldn't need shortcodes with SCN. for Site to Site SCN you'll need H.323 not sip.

I know you said trace is hard to get right now. When you get it that'll help out.

 

[smokinjoe2938]

HE IS NOT USING SIP!!!!!!!!!!!!!!!!!!!!

acss sme acis sme acss cm 5.2.1 acss cm and cmm acss aura messaging.

 

[element4749]

Right, so under Line --> I don't have any SIP Lines. I have H.323, a PRI, Some Analog Trunks, but not SIP. Nothing is defined under Line for SIP specific settings. I am relying on my local IP routing.

That is good to know though.

Ok, yea once I get a trace i'll take a look and post. Thanks again.

 

[element4749]

Lol.

 

[driven0]

My apologies, I need to read a little better.

blonde moment there, trying to work a helpdesk call while typing responses. Sorry about that.

 

[element4749]

Alright, so after a trace, internal calls from site A via SCN H.323 Trunk, to Site B's twinned extension is not sending any CALLING ID. Its completely blank.

Twin Mobile Delay Timer Expired - Initiate call to Mobile
64807459mS PRN: Setting configured voice gain for ch 23.
64807459mS T1DSP: PRIU DSP 3: channel 23 (timeslot 46), restore gains tx 10, rx 10
64807459mS CMLineTx: v=9
CMSetup
Line: type=Q931Line 9 Call: lid=0 id=2401 in=0
Called[XXXXXXXXXXX] Type=National (2) Reason=CMDRdirect Calling[] Type=National Plan=ISDN

 

[CarGoSki]

use sysmon on site with PRI and turn on pri layer3.
You will see ISDN transmit packets that show that calling party and called party numbers.
That is what you are sending to the carrier to process.

You can create a new ARS form for the SCN site that does not contain any S or I in the Tel Num field so there is no number to overwrite before the call is sent to the provider.

You can review the h.323 traces to determine the same calling party information to determine where the number goes missing.

 

[element4749]

Ok, so its been a little while for me, but from what it looks like under the specific ISDN L3 trace is that its not sending the CallingPartyNumber Information Element. From what it looks like the H.323 traces are showing the specific information elements for that calling local user extension all the way until it hits the ISDN. This happens to be only 4 digits, as that is all that is needed between SCN for inter-site dialing.

The only information elements being sent to the ISDN are BearerCapability, CHI, and CalledPartyInformation.

Unfortunately, I cant seem to find where or why its not sending CallingPartyInformation to the ISDN. Perhaps my first paragraph in this post is wrong, but i can see the information element for Calling in both the setup and alerting stages of the call process. Something has to be causing it to not send it, any more detail on where specifically I should look?

I really appreciate the post CarGoSki, it got me pointed in the right direction at least.

 

[element4749]

Hey all, its been a while since I have revisited this, however I still don't have it fixed. I was hoping to bump this in the hopes that someone can help me out.

Just to summarize, If I dial 4 digits for extension to extension calling between my two sites via SCN H.323 trunk, when the destination extension twins to an external cell phone, the originating caller ID does not display the full DID number of the extension that originated the call.

Has anyone ran into this issue?

 

[amriddle01]

You will not fix this, it's not broken as such. Original caller ID passing is for external calls, that's how the system is configured to work, it isn't going to pass the internal extn number of an SCN call it was never designed to do this. It's looking for a received caller ID to pass which is non existant, so it sends nothing

 

[element4749]

The truth hurts. I really appreciate your post.

 

[Westi]

You could probably get it working with SIP

Joe W.

FHandw, ACSS (SME), ACIS (SME)


“This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter