SCN Calls often unobtainable 3

[tipu2010]

Hi, am setting up a SCN between main office IP500 (v5.0.22) and branch office IP500 (v5.0.22) over a VPN with CISCO ASA5510 firewalls at each site.

1608 phone screen often shows "CALL:UNOBTAINABLE" when SCN extension is dialed.

10% of calls go through on first dial
40% of calls go through on second dial
30% of calls go through on third dial
20% of calls will require more 4 or more redial attempts before getting connected to the remote extension.

This happens when calling both ways round.

During the cause of the call the voice may go silent/missing for two-three seconds but line does not drop and then conversation continues.

 

[amriddle01]

You need some monitor traces, I suspect they will show the network going out of order, basically the VPN isn't very stable I imagine, what's the specs of the DSL links on each site and are they from the same providor etc

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[Bas1234]

Try to let them reboot the ASA, seen a lot of strange things with them. Also ASA's going in to survival mode without any failures.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________

 

[edmana]

You may also want to check if ports are closing after X amount of time. A site I worked on had Sonicwall and video conference stuff was crapping out consistently. We found that there was a 15 min timeout on outbound TCP connections. Shut those off and haven't had a VC or unobtainable since.

 

[tipu2010]

@Bas1234 - Let me reboot the routers now and see if there is any change.
@edmana - We also have Polycom Video Conf. When we turn off H323 Inspection the video conference cannot work. So they are on. But the calls drop after exactly 2 min unless the user presses more buttons during the call. We have adviced users to press buttons during calls.
@amriddle - The two sites are interconnected by VSAT through the same provider. I will paste some logs shortly.

 

[tlpeter]

Do the routers use fixup's ?
It sounds like keep alive packets are not received by the other end.


Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

 

[kwing112000]

That drop at 2 min is probably the H323 inspect. i had the exact same issue.

Kevin Wing
ACSS Small and Medium Enterprise (SME) Communications
ACS- Implement IP Office
ACA- Implement IP Office
Carousel Industries

 

[tipu2010]

Yes the CISCO ASA firewall use fixup and I need to keep using it because if i turn them off the Video Conference stops working.

What causes the calls to go through one time and another time does not?

Below is a trace of a call that did not go through
12/2/10 6:29:47 PM-886ms Extension = 551, Digit dialed, Digit = 3
12/2/10 6:29:47 PM-901ms Call Ref = 176, Originator State = Dialling, Type = User, Destination Type = none
12/2/10 6:29:48 PM-470ms Extension = 551, Digit dialed, Digit = 5
12/2/10 6:29:48 PM-760ms Extension = 551, Digit dialed, Digit = 3
12/2/10 6:29:50 PM-762ms My buttons = 1, Call Ref = 176, Originator State = Dialling, Type = User, Destination State = Seized, Type = Target List
12/2/10 6:29:50 PM-775ms Line = 21, Channel = 1, Line Ref = 1470, Q.931 Message = Setup, Call Ref = 176, Direction = From Switch, Calling Party Number = 551, Called Party Number = 353
12/2/10 6:29:51 PM-857ms Line = 21, Channel = 1, Q.931 Message = CallProceeding, Call Ref = 176, Direction = To Switch
12/2/10 6:29:51 PM-860ms My buttons = 1, Call Ref = 176, Originator State = Dialling, Type = User, Destination State = Dialling, Type = Trunk
12/2/10 6:29:52 PM-913ms Line = 21, Channel = 1, Q.931 Message = Alerting, Call Ref = 176, Direction = To Switch
12/2/10 6:29:52 PM-916ms Call Ref = 176, Alerting, Line = 21, Channel = 1
12/2/10 6:29:52 PM-917ms My buttons = 1, Call Ref = 176, Originator State = Ringback, Type = User, Destination State = Outgoing Alerting, Type = Trunk
12/2/10 6:30:21 PM-859ms Line = 21, Channel = 1, Q.931 Message = Connect, Call Ref = 176, Direction = To Switch
12/2/10 6:30:21 PM-869ms My buttons = 1, Call Ref = 176, Originator State = Connected, Type = User, Destination State = Connected, Type = Trunk
12/2/10 6:30:21 PM-869ms Call Ref = 176, Answered, Line = 21, Channel = 1
12/2/10 6:30:22 PM-259ms Extension = 551, Switchhook, Status = On
12/2/10 6:30:22 PM-263ms My buttons = 1, Call Ref = 176, Originator State = Clearing, Type = User, Destination State = Connected, Type = Trunk
12/2/10 6:30:22 PM-263ms Call Ref = 176, Disconnect from Originator End
12/2/10 6:30:22 PM-264ms Extension = 551, State = Busy Wrap Up
12/2/10 6:30:22 PM-270ms Extension = 551, Button = 1, Idle
12/2/10 6:30:24 PM-270ms Extension = 551, State = Idle

 

[amriddle01]

I have had a similar issue with Cisco ASA's but it was one call worked the next one didn't, no matter how long you left it between calls it was always every other call failed, never found a resolution. But I proved it to be the Cisco's by directly connecting the kit and it worked, then via the Cisco's it didn't but I left the company and left the network guy scratching his head

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[tipu2010]

I have had a closer look at it and it seems like when a SCN extension is dialled, most of the time the system thinks it is an outside line and tries to dial it out through the analogue trunk lines.

I thought the system should first match to an extension (including the SCN extensions) before attempting to look up the call routes? seems not to be the case here. How could I work around this?

 

[tlpeter]

So this proves that the SCN is not working at that particular moment.


Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

 

[tipu2010]

At site A, I have extenions 551 and 552. At site B i have extensions 351 and 352. I use 551 to call 351. And when they are in the middle of a call that is going on well, I use 552 to call 352 but get "CALL:UNOBTAINABLE". If I keep re-dialling the call will eventually go through. Meanwhile 551 and 351 are talking clearly.

Although the call keeps failing to go through, it shows the name of the user of extension 352 each time.

Additionally I have noticed that when it gives "CALL:UNOBTAINABLE" it actually selects the default system ARS and tries to route the call to an analogue trunk instead of seeing from the SCN that this is a valid extension number.

 

[amriddle01]

If at the time you dial the system can see the SCN as down it will inspect the ARS entries for an alernative route, that is standard behaviour to allow fallback. It is an issue with the Cisco's I just never had the time to force my old network guy to find the solution

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[tipu2010]

But at that time i am dialling there is another call going on on the SCN meaning the SCN is up.

 

[amriddle01]

I know, but the Cisco isn't passing the info through correctly and so the second connection message does not get passed and the system see's it as Network Out Of order and so looks for an alternate route. I think a proper monitor trace will show this not just a snippit from SSA. Even when the system thinks the network is up Routers messing with packets will cause a call to fail in odd ways

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[xlr8neo]

Hi, can you set up a short code with 5XX/./dial/trunk group for other site, if that is the ext range at the other site and point it to the trunk group you have created for the other site.

This will eliminate some of the problems with SCN related issues on most networks and if works will prove a network issue and not the ipo.

will pass calls ok, other features of scn will be intermittant

Light travels faster then sound...which is why most people appear brilliant until you hear them.

 

[TheSmash]

Some of this may be useful to anyone having problems with SCN. V5 especially seems to cause a lot of problems.


Cisco PIX:
no fixup protocol h323 h225 1720
no fixup protocol h323 ras 1718-1719

Cisco ASA:
policy-map global_policy
class inspection_default
no inspect h323 h225
no inspect h323 ras

-------------------------------------

How To: Turn Off h.323 ALG's for VoIP in ScreenOS 5.0.0


________________________________________
SUMMARY:
How To: Turn Off h.323 ALG's for VoIP in ScreenOS 5.0.0
PROBLEM OR GOAL:
h.323 Avaya 2640 phone registers "No Signalling connection" Error - Invalid TPKT value (1066)
SOLUTION:
There may be times where you will need to disable ALG for VoIP in ScreenOS 5.0.0. Some VoIP phones produce fragmented packets that is difficult for ScreenOS 5.0.0 to handle. As a workaround, disable the ALG for VoIP, and communications should succeed. ScreenOS 5.1.0 does a better job at handling fragmentation.
To disable the ALG, apply the following commands from the CLI (either console, telnet, or SSH):
unset alg q931
unset alg h245
unset alg ras

http://kb.juniper.net/InfoCenter/index?page=content&id=KB7408

ACSS (SME)

I never touched anything...

 

[tipu2010]

The network is using CISCO ASA but if I turn of H323 then the video conference between the sites does not work, and I need that too.

 

[tlpeter]

Try it.
If that works then call the video conference guys to fix it.


Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

 

[hairlessupportmonkey]

I dont understand why turning off the h323 inspect maps causes your video conference to stop?

Turning off the inspect maps simply stops the asa from inspecting the traffic passing through it.

the IPO is rather particular about its h323 packets being messed about with. You might need to consider whats more important right now and maybe consider if the ASA is the right product.

have you considered putting the IPO on a different network on the ASA and use LAN 2 on your IPO, then create your SCN on a seperate network. you should then be able to create inspect maps for different networks, but im not in front of one at the moment, so you will need to have a look on ciscos web site for some help on that one.

ACSS - SME