Showing wrong code

[mikeasa]

We are sending traffic from a Lucent G3 TDM to a Cisco 5300 and out voip. What happens is if the voip carrier sends back USER BUSY (17) the cisco now sends to G3 Destination out of order. Please tell what info to post so I can get help.

 

[ISDNman]

Why is this a problem?

Sounds like CIsco has not fully implemented all the cause codes (though it sure seems odd that they didn't implement cause 17).

But destination out of order should result in the user hearing busy or network unavailable (fast busy) so the user should ge tthe idea when s/he hears this.

 

[mikeasa]

Some times it works correctly. But when it is incorrect they get a fast busy my G3 gives a verbal msg that they have reached a nonworking number and people start getting upset.

 

[ISDNman]

Yeah, I can see how the interecept message could cause users to be confused.

Short the short term, till the problem is resolved, you may want to change that intercept announcment to "You have tried to call a number that is busy or is no longer in service. Please try again later"

Since it works sometimes I bet the problem is not the cause code, but the cause location. I would do a prptocol log at the VOIP side and see if the problem calls show a different location code than the working calls.

My best theory is that the calls that work properly have cause 17 with a location of 80 (user).

My guess is that in cases where it doe snot work you are getting a cause 17 with some other location. The location codes are:

80 = User
81 = private network serving the local user (e.g. local PBX)
82 = public network serving the local user (e.g. local CO)
83 = transit network
84 = public network serving the remote user (e.g. far end CO)
85 = private network serving the remote user (e.g. far end PBX)
87 = international network
8A = network beyond interworking point (e.g. far end non-ISDN network such as POTS or Switched 56)

I have seen a number of networks where only a subset of cause codes are implemented. So, for example possible the transit network is unable to handle the call. In that case it really should send one of the following:

Cause 42 Network Busy, try again later.
Cause 44 No channel available
Cuase 31 network disconect

But if the transit network's equipment has not implemented those causes, it might be sending Cause 17 with a location of 83.

In that case the G3 may be trying to be helpful by changing this to a more useful cause.

One big clue is to try and find out tha tif when this occurs if the line being called is acutally busy. If not my theory looks very good.

Sorry, I have no idea how to get a protocol trace off the CIsco or G3, but I would definitely try to get one (preferably look as close to the VOIP sned of things as you can).

Best of luck.

 

[mikeasa]

OK in our testing we produced all of the problem with in our network. Meaning I would send call to one of our switches that would terminate to a Verizon pots line.

I make call in this order

1. terminating phone on hook results code 16 in cisco
2. terminating phone off hook results slow busy 17 in cisco
User busy
3. terminating phone off hook results slow busy 17 in cisco
User busy
4. wait 5 10 sec
5. terminating phone off hook results fast busy 27 in cisco
Destination out of order

Keeping all varibles the same for the test the 17 and 27 would come back at different times all the time knowing that
the terminating Pots line was truly busy not out of order.

And this occours in different 5300's different IOS's

 

[ISDNman]

Where are the trunks out to the public telephone network? On the Avaya, the CIsco, or somehwere else?

 

[mikeasa]

I am not sure what you mean but in the Avaya (where call originates) public-network and fast busy

In Cisco (from Avaya) I dont know how to check. code 27

In my Softswitch (from Cisco) Dont know code 17

At Voip level carrier (destination) Dont know. code 17

 

[ISDNman]

Which switch has the POTS line you refer to above?

 

[mikeasa]

The last leg of the call going to the voip carrier. They terminate to the a verizon posts line. Which is one of my numbers that i can answer here where I am. In other words I send call from my desk extention to the G3 from there it goes to my cisco the to my soft switch the to my LD carrier which is voip. but they have to route it back throught their network however and it ends back on my private lie which is a verizon pots line.

 

[ISDNman]

So, from the CIsco and the Voip carrier it is always at cause 17?

IN that case the only logical case is that the location varies (or the Avaya acts inconsistently which seems unlikely).

There must be a way to look at the protocol comin gin from the VOIP carrier at the cisco. I'd look there next. Sorry, I can't tell you how to look, you'll probably need to talk to CIsco.

Does the Voip carrier support soft phones? If so, do you get the same inconsitent behavoir repeatedly calling using a soft phone (or ISDN phone). That would be a big clue.

In any case... if it is always a cause 17 leaving the CIsco headed to the Avaya then the G3 should not be changing the cause code (no matter what the location is). If you are certain this is the case ask Avaya why they change the cause code.

Good luck.

 

[mikeasa]

Ok we are missing each other here the code 27 starts at the cisco level evrything be for that shows a code 17. Its is in the cisco I get the problem.

 

[ISDNman]

OK, that would sounds right- cisco not following standards? Cisco not getting "real tlephony stuff" never. Just like Microsoft aleays follows standards.

So either cisco needs to fix it, or you need to change your intercept message on the Avaya to one less "scary" to user.

Now, beofre you go to CIsco it would be interesting to try and determine what is varibale. SInce it is always a cause 17 then the next thing would be to look at the carrier signaling to see if the location varies. If it does yhou can tell CIsco that the location code as well as the cause code must be passed along without changes. Just becasue (perhaps) sometimes the location code indicates it is not the user that is sending the "user busy" does not mean one should change it. Don't try and correct soemoen else's mistake - that gets you into trouble.

The onyl other possibility is that there is something else in the calls setup (SIP or H221) that is variable in this case. If you verify the location is always the same that would be the main remianing possibility.

If you don't have a protocol analyzer you can use at the IP level to diafgnose this stuff you should look into it. There are a couple of free ones available.

Good luck