Pradeepgali,
Alright I believe that I understand your question and you are asking if the system can load balance SIP Trunks across several IP Addresses for Registrars?
If that is the case then you want to know if the 5000 can register with both 97.79.104.70 and 97.79.104.71 at the same time or just which ever one is available? For my answer I suggest you look at how we setup our SIP Trunk Groups. We have two methods for registration and either one or the other can be used, but not both at the same time if that makes sense.
Registrar IP Address: Is the SIP peer registrar server IP address. If this value is specified, the SIP REGISTER is sent to this address. The range is 0.0.0.0–255.255.255.255; the default is 5060. After you change this value to a valid IP address, you cannot change it back to the default value.
Registrar FQDN: The SIP peer registrar sever fully qualified domain name (FQDN). If this value is specified, the SIP REGISTER is sent to this address, but only if the Registrar IP address is set to 255.255.255.255. Enter a domain name, up to 254 characters, in the text box.
Now, some providers use multiple IP addresses to send SIP messages to the 5000 and in that case we need to add all of the IP addresses or FQDNs other than the primary IP/FQDN to the Alternate IP/FQDN List for all calls to be successful.
So, yes we can register both if we create two separate Trunk Groups and each one is setup to look at just one of those IP Addresses using the Registrar IP Address. The other option is to have the FQDN do the load balancing for registrations; which is usually how you would want to configure this option.
Outbound:
1. Will it support a round robin search method.
That would depend on how you configured the Registrar, but in either case it would send the request to the Registrar to get the next available trunk. So the best case scenario would be to use the FQDN and let it do the load balancing per industry standards.2. Will it support a primary, failover search method. If so is it based on:
a. IP address reachability
b. Primary sending a call reject and the Mitel 5000 steps over to the other call choice.
If you are using the Registrar IP Address then no as it would only know about the one IP Address to work with, but you could try putting in the other Registrar IP Address in the Alternate IP/FQDN List and see if it does failover; I for one have never had a customer try this setup.
If you are using the Registrar FQDN then that server should do the failover search unless that server is down. Again, you could try putting in anotehr FQDN or IP Address in the Alternate IP/FQDN List to see if it does failover; again I have not had this type of setup.3. Does the equipment generate SIP option pings to both destinations concurrently to insure reachability?
The system does have the Ping Option under Keep-Alive that can be turned off and on and by default it is set to Yes. As for how it handles multiple destinations my assumption would be that it would go only to the primary IP or FQDN. At this point no one has ever asked me that and I haven't had a need to know so I never asked Mitel how it would be handled. Unfortunately if it isn't broke I do not try to fix it or for that matter even think about it.Inbound:
1. Can the equipment support calls being delivered from two sources?
Yes, as stated earlier in the post some providers use multiple IP addresses to send SIP messages to the 5000 and in that case we need to add all of the IP addresses or FQDNs other than the primary IP/FQDN to the Alternate IP/FQDN List for all calls to be successful.2. Will the equipment respond to both center’s SIP option pings?
It should respond to any pings sent to it regardless of where it comes from as long as they are listed in the Alternate IP/FQDN List.I don't think that many of these options are explored by customers in my area so there may be others in the forums that do more work with SIP Trunking as it isn't used much by customers in my area. So, if you get no other answer to this question then you will need to find out the old fashion way through testing unfortunately the good part is that you are equipped to do that unlike most of the technicians or engineers visiting these forums. If you find out some of these answers then please let us know what you do find out about it so the information can be spread amongst the masses.
Thanks,
TE