SCN is only supporting inbound traffic.

[trinetintl]

We moved a customer's IP office 500 R5(26) to a new office, they got temporary internet and SIP trunks, their firewall guy set up a new firewall wall with a new subnet and VPN tunnels to link this site to about 3 other sites. We went into the phone system and changed the SCN IP addresses and IP Routes to allow voice traffic. All of the SCN show that they are up, we do not see any errors, however, what is weird is that if you dial extension to extension, the SCN trunk is currently only supporting inbound traffic and not outbound. SIP trunks are working, no problems there.

What we are experiencing is that when we dial any other extension from this site the system comes back with a busy signal. In SSA we get " Line = 9, Channel = 1, Q.931 Message = ReleaseComplete, Call Ref = 34, Direction = To Switch, Cause Code = 17" in monitor we see "CMExtnEvt: nouser891: CALL LOST (CMCauseBusy)". We have scanned the firewall and the IP Office configuration, we can ping everything, and we have literally hit a mental wall. Any help will be greatly appreciated.

RE

http://www.trinet-intl.com

APSS, AIPS

 

[trinetintl]

I was going through the monitor output and I noticed the "Cause-17, User busy". What is that all about? We tried dialing hunt groups, extensions, you name it, they all come back as User Busy.

RE

http://www.trinet-intl.com

APSS, AIPS

 

[derfloh]

Sound like a license issue. The SCN channel licenses are only needed for outbound calls. Inbound is free.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[trinetintl]

derfloh, boy I wish that was the problem, the site was working before the move and it has 4 valid IP500 Voice Networking Channels, actually, when the system was relocated this past Friday I closed the service ticket with everything working including the SCN. I went back in late that night to check to see why the SIP trunks were not able to dial and connect to their Afterhours answering service, I ran out of ideas and gave up decided that if I waited until Monday and put more heads into the problem we could get it resolved. I was not aware that the outbound SCN was no longer working, I found about that this morning and we have been trying to figure it out all day long.

RE

http://www.trinet-intl.com

APSS, AIPS

 

[critchey]

So this system is R5 correct? So you have shortcodes in place pushing the extension calls over the H323 line? How are the shortcodes setup? How is the H323 line setup (what is the outgoing groupID)? There is no conflict with GroupIDs of the H323 line and SIP trunk (or any other lines present)? If you dial the same user on the local system it does work I am guessing?

You have SIP trunks working on a R5 system?! That seems impressive in and of itself TBH...

The truth is just an excuse for lack of imagination.

 

[Okkie26]

Do you see the call entering the called system?

Check SSA to see if a channel is occupied (if only for a split second)

 

[trinetintl]

critchey, thank you, I appreciate the kind words about the SIP trunks actually for this particular site, it was the first one out of 5 that we flipped to SIP and it was an explosive conference call with the rude Spectrum tech at the time of turn up and cutover because he thought we did not know what we were doing and he also taught that R5 was not compatible with their SIP trunks. We made serval requests for him to make changes on his side, he absolutely refused, he was adamant that the problem was the IP Office and the site was not switched. Just to prove that guy wrong, we went running over to the site that was scheduled for the next day, deployed the licenses, got the dongle and the SIP trunks plugged in that old and still running 406, rebooted the system and the service came online, on the first try without any help from Spectrum, I was pissed but I had proved my point!!

We tried shortucuts, without shortucts, changing outgoing and incoming group ID, creating a new H323 pointing to a different IP Office, nothing.

Okkie26, We see traffic on the IP trunk but only on one side, it looks like there is a one-way wall blocking the IP trunk. In SSA using trace all, traffic hits the IP trunk but it never reaches the other side, not even a blink, it just ends with Code 17. What is strange is that the customer called me yesterday and told me that from the central site or the inbound side he was able to ring one particular extension at the remote site, however when he tried to dial a different extension he got an Incompatible message. What makes it even more complicated is that he told me that sometimes it just works, out of the blue, and just the same way it stops working, now you are talking about and intermittent problem and those are even harder to troubleshoot.

At this juncture, I am beginning to lean towards some sort of hardware issue maybe with the controller unit or the VMC card, what do you think?

RE

http://www.trinet-intl.com

APSS, AIPS

 

[Okkie26]

Routing issue or firewall. Like you mentioned.

 

[critchey]

It is most likely routing or firewall but at that release you would absolutely need shortcodes to route across the line.

Example:

You have extensions in the 200s at SiteA, H323 line is outgoing groupID 20
You have extensions in the 300s at SiteB, H323 line is outgoing groupID 30

SiteA shortcode
Shortcode: 3XX
Feature: Dial
Telephone Number: N
Line Group ID: 20

SiteB shortcode
Shortcode: 2XX
Feature: Dial
Telephone Number: N
Line Group ID: 30


The truth is just an excuse for lack of imagination.

 

[derfloh]

Short codes are not needed to dial between extensions or hunt groups in an SCN.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[quazimotto]

Can you ping both ways? Sounds like a security policy on one side was not applied.

 

[trinetintl]

quazimotto, Yes, we can ping both ways and yes, I still have the firewall in the back of my mind because they have somebody external to the organization managing it. Maybe after I had everything working, they went back in and changed something, I don't know. I am trying to get my hands on the old firewall to see if I am able to login in and compare it to the new one.


RE

http://www.trinet-intl.com

APSS, AIPS

 

[IPGuru]

If you can get wire shark running at both ends you should be able to see the SCN traffic leaving one switch & failing to be recieved at the other.
once you have this evidence you can pass it back to the firewall guys to "Go Fix".




Do things on the cheap & it will cost you dear

 

[derfloh]

Probably NAT is enabled in one direction...

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN