SIP Proxy as HA for SIP Server

[Dionysis]

I'm trying to configure SIP Proxy as an N+1 setup for SIP Server HA instead of using address takeover.  To start with I've set up a 2 proxy servers and a single SIP Server in my test environment but I'm running into issues with IWS connecting to the proxy.

Has anyone successfully used SRV DNS records with IWS?  I'm trying to get a cluster of SIP Proxy servers going and can get IWS to communicate via 1 SIP Proxy without too much issue, however getting it to use the DNS SRV record is proving a challenge.

If I use "domain.com" as the sbc address it resolves the SRV record correctly using "_sip._udp.domain.com", then attempts to send invites to "sip:domain.com" and fails.  A packet capture on the desktop box shows absolutely no SIP messaging being sent in this case.

Clearly I'm doing something wrong, but I can't figure out what.  Documentation on configuring SIP Proxy is quite vague when it comes to the DNS requirements, just says you need an SRV record and to check the DNS Configuration documentation.  For IWS there is absolutely no docs on using SIP Proxy that I can find either.

[genesysguru]

Not tried it myself - you are breaking new ground here! Please report back your findings.

Regards

[genesysguru]

PS: I note in the SIP Proxy Deployment Guide:

As of March 2013, SIP Proxy has been tested with only two SIP endpoints - the Genesys SIP Endpoint v8.1, and Polycom SoundPoint IP Phones; additional endpoints are scheduled for testing. So in theory IWS should work fine.

[bublepaw]

First try with Bria Counterpath of XLite to see if DNS is configured correctly - they both support SRV record resolution. I am not sure which version of IWS endpoint supports proxy - new restricted version of old version. I use following DNS entries and they work with hardphone and proxy. Phone is configured to register at sip01proxy.genesys.test.

; sip01proxy definition - for endpoint that supports only A record
sip01proxy.genesys.test. 300 IN A 1.1.1.1
sip01proxy.genesys.test. 300 IN A 1.1.1.2
; for endpoint that supports SRV
proxy01.genesys.test. 300 IN A 1.1.1.1
proxy02.genesys.test. 300 IN A 1.1.1.2

_sip._udp.sip01proxy.genesys.test. 300 IN SRV 0 50 12060 proxy01.genesys.test.
_sip._udp.sip01proxy.genesys.test. 300 IN SRV 0 50 12060 proxy02.genesys.test.

_sip._tcp.sip01proxy.genesys.test. 300 IN SRV 0 50 12060 proxy01.genesys.test.
_sip._tcp.sip01proxy.genesys.test. 300 IN SRV 0 50 12060 proxy02.genesys.test.

[genesysguru]

Pawel,

Great response - straight from engineering. Thanks! 

[Dionysis]

Thanks for the response Pawel, I have confirmed that X-Lite can start and register via the proxy.  I did have an issue with the configuration where I was using short names for the SRV resources instead of FQDN's, once I fixed this the registration occurred.

However IWS is still not playing ball.

Could you tell us which version of IWS supports using SIP Proxy?  We are using version 8.1.301.14

[bublepaw]

Hi,

options required for IWS to support proxy are:

- sipendpoint.sbc-register-address
- sipendpoint.sbc-register-port

Support is very basic currently and mid dialog are still sent to failed proxy

[Dionysis]

Thanks Pawel, I've been leaving the port blank as it should not be required when using SRV records.

I'll give it a go with the port included.

[bublepaw]

Try using default port 5060 - my testing shows that using default port makes life easier (much more ) - even if SRV fails system revers to using 5060 when only name is specified

[ryusuf]

Hi,

I have been configuring this SIP-Proxy approach for a quite a while now. Unfortunately, i am getting up this error in the SIP server logs.

17:03:14.538: CUserPublicationManager::Start: User publication is not enabled
17:03:14.538: InitReportOperationalStatistics::ProcessId 996.
[b]17:03:14.538: GSDNChecker::GDNS: SRV record unresolved: sip-proxy.genesyslab.com, status -1 (-1: Host or address not found)
2015-07-21T17:03:14.538 Std 52023 GDNSChecker: Can not resolve hostname: sip-proxy.genesyslab.com as SRV record.
17:03:14.538: GSDNChecker::GDNS: Try to resolve A record sip-proxy.genesyslab.com:5060 instead[/b]
17:03:14.538: GSDNChecker: AddChecker for 10.33.48.153:5060
17:03:14.538: TRANSPORT[0x2] [0,UDP] 10.33.48.153:5060 handled connect
17:03:14.538: $+NET:SIP::0:0
17:03:14.538: SIPTR: Received [0,UDP] 361 bytes from 10.33.48.153:5060 <<<<<

I am pretty sure this has something to do with my DNS configuration which is as below

SRV Record
---------------
_sip Service Location (SRV) [1][0][5060] sip-proxy.genesyslab.com. static

A Record
---------------
sip-proxy Host (A) 10.33.48.153
sip-proxy Host (A) 10.33.48.156


Can anyone enlighten me where am i going wrong?

Thanks in Advance

[Kubig]

Do you using DNS SRV record or just A record (depends on your SIP endpoint features/capabilities)?

[ryusuf]

Hi Kubig,

Can you please elaborate your question?

As per the SIP Proxy deployment guide, it is mentioned that
[b]Configure the Domain Name System (DNS) Server to resolve the SIP Proxy FQDN by A and SRV records.[/b]

That is why i have create both SRV and A record in DNS.

[cavagnaro]

And your client PC can resolve them? Both SIP Server and SIP agent should use this DNS server

[ryusuf]

Yes both of them are using the same DNS server.

[b]Now the question arises is how do i identify whether the client is able to resolve[/b]. Because when i ping the address sip-proxy.genesyslab.com, i get success.

When i do a nslookup in the client PC with entering the command
nslookup
set type=SRV
_sip._udp.genesyslab.com

I get the result with the SRV records.

[ryusuf]

Hi All,

Can anyone please tell me which version of IWS Sip endpoint is supported with SIP-Proxy approach.

Because currently after moving to this approach, the IWS client is misbehaving in really weird manner.
[list]
[li]The IWS clients goes into out of service and sometimes comes back.[/li]
[li]Some times the calls get disconnected in between, when looking the logs of SIP server we can see that RequestReleaseCall was initiated by IWS client. however, agent did not initiate disconnect[/li]
[li]Sometimes all the IWS client goes into Out of Service state for voice media. [/li]
[li]Sometime it works perfectly fine. [/li]
[/list]

I know this is weird. But i don't know whether it is due to Sip proxy approach.

How can we test whether DNS SRV resolving is correct?

Appreciate some information on sip-proxy by anyone who has implemented it successfully.


Thanks in advance