Entity Links

[wpetilli]

I have 3 ASM's and they are all linked to 1 SMGR. I have all the SIP entities created and now am in the entity link section. I created an entity link from ASM1 -- ASM2. Do I need to create one from ASM2 -- ASM1 or does my first entry take care of that?

 

[kyle555]

I believe you're good one way

 

[wpetilli]

I'm building out this environment since the ASM's are not in production. My 2 CM's are created as SIP Entities, along with the ASM's. I have entity links between the ASM's. I created SIP Trunks from my CM to each of the ASM's. I added a routing policy and dial pattern for 1 specific extension on the far end. In my RP I put in all of the SIP TG's. If I deny service to ASM1, the SIP TG from CM stays up in/service and I get fast busy. I have to busyout the signalling group to get the call to use another TG, and ASM. I'm trying to prove off that the call will process no matter if an ASM is down. What is the best way to test this because I would have thought the denied ASM would force the TG to go out of service, and it didn't.

 

[kyle555]

I believe CM's mechanism to determine if a SIP signalling group is in service is to see whether it gets a SIP reply to a SIP PING/OPTIONS message.

That SM says "403 Forbidden - I'm administratively out of service" is probably enough to get CM to see the SIP messaging is "up". Stupid, but I think that's how it is. If you want to simulate an ASM down, shut the interface on the SM100, or just shutdown the ASM altogether and see if you're testing holds up.

 

[wpetilli]

Thanks, that worked (disabling the SM100 interface); However, it took a solid 5 minutes after I shut the interface for the TG to go out of service. Is that timer a setting in ASM or in CM?

 

[wpetilli]

Matter of fact it took 8.25 minutes for my CM TG go out of service.

 

[kyle555]

Try making a call as soon as you yank the network interface, might cause the maintenance tests to happen faster