SRV Failover using Transparent SIP Proxy

[ss_brandon]

We're attempting to test SRV failover of phones while using transparent proxy.  Upon taking down the primary server, the adtran is returning a 480 routing failure to the phone which is preventing it from failing over to the secondary server.  Is anybody successfully using SRV to seamlessly failover to secondary SBC's?  If so...how did you accomplish it?

[jayh]

With the TA900 series it just works. Make sure your SRV records are correctly formatted in the DNS server.

Do a "show hosts" on the Adtran device, you should see entries along the lines of: 

_sip._udp.domain.tld    sticky 302	SRV   5060	1	50 sbc1.domain.tld
_sip._udp.domain.tld    sticky 302	SRV   5060	2	50 sbc2.domain.tld

sbc1.domain.tld   sticky 363	A	-	-	- ip.of.primary
sbc2.domain.tld   sticky 504	A	-	-	- ip.of.secondary

[kshymkiw]

I am getting the exact same thing as your are.  For a moment in time it seems to make the Reg work, and then it quickly flips to 480 Routing Failed.

I keep getting Messages of the SIP Proxy adding the user, then expiring the user.  Here is my SIP Proxy config:

sip

sip udp 5060

no sip tcp

sip proxy

sip proxy transparent

sip proxy duplicates-allowed

sip proxy grammar proxy-id contact-user

The "show hosts" shows my SRV Records, and A Records:

_sip._udp.public-voice sticky 43137   SRV   5060    20     - sbc01.xxxxxx.xxxx

_sip._udp.public-voice sticky 43137   SRV   5060    10   100 sbc01.xxxxxxx.xxx

sbc01.xxxxxx.xxxx   sticky 43137   A        -     -     - <IP of Primary>

sbc01.xxx.xxxxxxx.xxx sticky 43137   A        -     -     - <IP of Secondary>

This is what keeps getting spewed on console every 30 seconds or so:

SIP.PROXY DB added proxy user <DN>@192.168.100.11

SIP.PROXY DB expired proxy user <DN>@192.168.100.11

[ss_brandon]

Not asking about the TA's -- we know that works fine.  This post is in the "NetVanta 3400 Series" section.

[kshymkiw]

I asked our Adtran SE about this yesterday.  He is checking to see if this is an acceptable configuration.  The way I interpreted his response to my email, was that he was unsure this was a supported deployment method.    

[ss_brandon]

We've also been working with our SE, TAC, and Engineering with conference calls and email the last month-ish.  Our understanding that Engineering is working on a fix.  We were supposed to have a conference call today, but appears it'll be pushed to next week now.  Need it working -- no geographical redundancy for any of our customers behind AdTran right now.  Not happy.

[kshymkiw]

Did you ever get a response to this?    

[ss_brandon]

Nothing yet.

[kshymkiw]

Bummer.  The only thing I heard from Pre-Sales Engineering was: "SRV is not specifically supported in our product. I'm not certain why you would be getting a routing failure or why the Proxy DB is aging out at 30 seconds either"

Which to me, I wonder why the device is even making SRV Requests, if SRV isn't supported.    

[ss_brandon]

Email received yesterday:

"I spoke with Product Management, TAC and or engineering will be contacting you with regards to a short term fix."

Haven't heard from them yet though.

[kshymkiw]

Please let me know what the Fix is for you.  We are getting ready to roll these devices, and implement SRV.  I would really like to have the Proxy + SRX Support.

[jayh]

The DNS doesn't look to be properly formatted. Try adding a weight as well as a priority to both SRVs. With only one entry per priority, the weight shouldn't matter but it may need to be present for the Netvanta to parse it correctly.

You have:

The "show hosts" shows my SRV Records, and A Records:

_sip._udp.public-voice sticky 43137   SRV   5060    20     - sbc01.xxxxxx.xxxx

_sip._udp.public-voice sticky 43137   SRV   5060    10   100 sbc01.xxxxxxx.xxx

Change the secondary to:

_sip._udp.public-voice sticky 43137   SRV   5060    20   100 sbc01.xxxxxx.xxxx

Not sure if this will fix it or not but it might. It works fine with our NV3120s. Don't forget to clear your DNS cache when you make the change (or wait a while).

[kshymkiw]

Both have a weight...0 is a valid weight as I want it to be a pure backup. Here is my DNS Zonefile entry for SRV:

_sip._udp.public-voice  IN SRV 10 100 5060      sbc01

_sip._udp.public-voice  IN SRV 20 0 5060        sbc01.ewc.acsalaska.net.

Are you also using SIP Transparent Proxy on the NV3120?  I believe this is interaction between the Transparent Proxy and SRV.

[kshymkiw]

Jay,

I went ahead and tried to add a Weight other than  0 to my entry.  This did not produce any different results.

Show hosts:

_sip._udp.public-voice sticky 43058   SRV   5060    10   100 sbc01.acsalaska.ne

_sip._udp.public-voice sticky 43058   SRV   5060    20    10 sbc01.ewc.acsalask

sbc01.acsalaska.net    sticky 43058   A        -     -     - x.x.x.x

sbc01.ewc.acsalaska.ne sticky 43058   A        -     -     - x.x.x.x

I am still seeing 480 Routing Failure with Transparent SIP Proxy enabled.  The only way I can get this to work is to turn off, Transparent SIP Proxy.

[kshymkiw]

Did you happen to receive an update with the fix?

[kshymkiw]

Have you gotten any word back?  My Ticket with Adtran TAC isn't really going anywhere...

[ss_brandon]

Sorry.  Nothing yet.  Rumor is that the code has been written, and is awaiting QA/testing.  Being told ETA is Q3 (unacceptable).

[kshymkiw]

So that was their solution was to write new code?  I agree it is completely unacceptable.  As I told Support, why is their Device asking for SIP SRV Records, if it doesn't support SRV to begin with?

I will push this through my account team too, and hopefully with multiple customers pushing, it gets release quicker than Q3.    

[Anonymous]

Brandon and Kevin,

We do support SRV records as both a DNS proxy and as a client. It sounds like you are expecting the ADTRAN to forward the SIP requests to one of the other hosts in the host table. The SRV records in the host table are not used by the ADTRAN for call routing decisions in your application (SIP Transparent Proxy). Those are there only for the ADTRAN to use in the event that it has to respond to DNS queries from your phone, in the event that we lose contact with the DNS server. It is up to your phone to make the decision about when and where to send SIP requests to its redundant servers.

As you both know, there has been a feature request submitted for the SIP transparent proxy to interop with Polycom’s geo-redundancy feature. The functionality needed to interop with this feature is being developed. Please contact your sales rep for the current timelines for those features.

Regards,

Rob

ADTRAN Support

[kshymkiw]

Rob,

I appreciate all the work  you put into my ticket, but I do believe this might not be correctly stating the issue.  I think the issue, is Adtran's AOS Transparent Proxy, is NOT making call routing decisions based on SRV Records in the Hosts Table.  This is the whole concept of SRV.  A device receives multiple records, and based on the devices own criteria, makes routing choices.

I feel you saying this is an issue with the way Polycom implements this, isn't quite fair to Polycom.  This happens to be the same issue with my Grandstream and Cisco SPA Phones.  Since by design  the Transparent Proxy is making the call routing decisions, the issue with implementing SRV is in the Proxy, not the Phone.

Kevin