SIP with Spatial Redundancy

[cavagnaro]

Hi guys,
I'm helping an OXE engineer on an implementation where customer has spatial redundancy (2 CPUs) enabled. Now when deploying SIP extensions he was facing the fact that after 32 seconds the call was released. While I was checking the traces saw that I never got an ACK message on the SIP Extension (external gateway) and therefore OXE launched a timer where he released the calls, OXE guy then told me effectively that there is a timer that is set at 32 seconds which is the lack of the ACK message.
So went dipper and compared my OXE (1 CPU) and his OXE (2 CPUs) messages and I see that in difference my OXE uses IP Address and his uses OXE name...(sip:6889@pbxalu) so trying to understand I figure out that would be because of redundancy in fact...now, what do I have to do with the DNS on the OXE and the endpoint to make this work? I tried to replicate the issue on my laptop using XLite and as user use the same 6889@myoxe instead of ipaddress and it fails, so adding the myoxe to my hosts file didn't work, adding it to the DNS Server didn't work, configured my DNS server to serve SRV records with _tcp._sip and _udp._sip and still nothing...what else do I have to do? I found a small reference saying "Configure OXE DNS"...but...what????

Any input will be great!

[alex]

Hi Cav
Spatial redundancy with SIP devices/gateways is a bit complicated comparing to a single CPU. But once you configure it according to the docs it works like a charm.
You are right for SR to work properly you should configure internal name resolver.

4.Activating the internal name resolver. This is mandatory for SIP end points.

Check netadmin section in System documentation?/Maintenance/Maintenance commands/netadmin/Operation
TC1180 is the answer and System Documentation/System Documentation/IP-PCX Networks/SIP/SIP Generalities.

[MrAnMo]

I've got the same problem with a customer in R9.1 patch 25a. After programming the sip trunk and doing a double bascul sip extensions are disconnected after 32 seconds and sip devices are disconnected after 4 seconds. This all because there is no acknowledge message. I've tried to replicate it in my company's lab but in lab with same release and patch setup everything was fine. Same phone in lab is responding to 200 ok message but by customer it seems to ignore that message and it didn't respond to it.

First I was thinking it was in the lan config so on Monday 24 jan I have a test in the same subnet so I'm sure it is no firewall issue. But now I'm thinking I have to need a total reboot. I will keep you updated about this problem. If anyone knows the solution please update this topic.

[oldboy]

We had the same issue with Polycom units when we implemented spatial redundancy, yes 100% you must configure internal name resolver, but i also found in the internal gateway we put the 2 cpu addresses, we also put the 2 cpu addresses in the dns of the polycoms and all work a treat, the biggest issue we found was Windows DNS didnt allow us to have 2 addresses for the same cpu name and would always go to only 1 address and not step over if not active

[cavagnaro]

Thanks a lot Alex, I think we achieved this to work on our lab
So we enabled the internal dns resolver (netadmin -p yes) and added on the sip extensions the OXE CPU IP address as DNS servers...so far it works fine
Thanks for the tip

BTW: No need for MS DNS Server and other options I did at all. OXE will be the DNS server that is why I added the two CPUs IP Address so when main goes down standby will start to resolve new name-ip address

[cavagnaro]

We had the same issue with Polycom units when we implemented spatial redundancy, yes 100% you must configure internal name resolver, but i also found in the internal gateway we put the 2 cpu addresses, we also put the 2 cpu addresses in the dns of the polycoms and all work a treat, the biggest issue we found was Windows DNS didnt allow us to have 2 addresses for the same cpu name and would always go to only 1 address and not step over if not active

Yes it does, however not using A types, but SRV types, it will give a list of servers with priorities that will handle the request. In OXE SIP Gateway you even have the option to choose between A or SRV types, but have no time to play with those yet...

[oldboy]

Agreed but SIP SRV requires a Cust to setup a sip srv which in this case they declined to do!

[cavagnaro]

Oh well my friend, that runs away from our hands... :S

[MrAnMo]

First I have to say thanks to hints which were given in this topic. My problem was also fixed by the given solution. My first set-up was that my 4135 set was connecting to both main addresses and so could work with the spatial redundancy. Unfortunately when I made a call with the 4135 set there was for 4 seconds audio and after that the connection was broken.

I I look in the trace I didn´t respond to the 200 ok message. If I look deeper in it I saw that the P-Asserted-Identity has the node name in it instead of the main ip address. I think, but I could be wrong, that this was the reason the sip set didn´t reply with a acknowledge.

Now I programmed with netadmin option 15 the dns. And give the 4135 the 2 callservers as dns servers. The sip setup to the node name and everything was working fine.

Many thanks for the hints in this topic. Stupid my that this option was not in my memory any more. For the one´s who like to see traces I´ve connected two traces one who is working one who is not. Maybe it helps someone else.

[inderdeepsinghtung]

pls help me i checked the mtw with same subnetwork conference does not break while cpu change over ,but in different subnetwork conference fail while changeoverand tell me what to do so it work i alredy enabled internal name resolver in netadmin of oxe,