Many times when i think about the behaviour of H323 and MGCP one think that commonly came to my mind is the call preservation.
after doing some research in internet i tried to consolidate the behaviour of call preservation in case of MGCP.
MGCP actually do a PRI backhaul to CUCM to pass the layer 3(q931) information to the CUCM from the gateway so What will happen if the MGCP gateway is registered to a Subscriber in a cluster and subscriber goes down.
The information that is received by the subsciber will be shared by the publisher , So if the subscriber goes down those information will be available with the Publisher.As the D channel terminate on the MGCP gateway so it will be UP
Now what will happen in case of SRST fall back ????
In case of SRST fallback as it will reset the PRI backhaul hence the Layer 2 (Q921 ) will also reset and the call will drop, so no call preservation will work in case of SRST fallback ..
after doing some research in internet i tried to consolidate the behaviour of call preservation in case of MGCP.
MGCP actually do a PRI backhaul to CUCM to pass the layer 3(q931) information to the CUCM from the gateway so What will happen if the MGCP gateway is registered to a Subscriber in a cluster and subscriber goes down.
The information that is received by the subsciber will be shared by the publisher , So if the subscriber goes down those information will be available with the Publisher.As the D channel terminate on the MGCP gateway so it will be UP
- CUCM send AUEP (Audit Endpoint) to the gateway to find the state of each B-channel
- CUCM send AUCX for any Endpoint for which the gateway reports a preserved call
- Send Q.931 Status Enquiry messages to the PRI device attached to the gateway to confirm the status of any calls CUCM believes are preserved.
Now what will happen in case of SRST fall back ????
In case of SRST fallback as it will reset the PRI backhaul hence the Layer 2 (Q921 ) will also reset and the call will drop, so no call preservation will work in case of SRST fallback ..