[SIPForum-discussion] Question regarding DNS SRV

[Javier Dejo]

What I understand is that your device should resolve the DNS records,
and try to contact the primary AS, and only contact the secondary when
the primary is down. Your device doesn't have to provide the DNS
service, it only has to be able to understand SRV records (which are
very similar to mx records).

 

Broadsoft primary AS is 70, secondary is 71

 

Javier

 

 

 

 

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Jeff Wright
Sent: Friday, December 14, 2007 6:27 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Question regarding DNS SRV

 

We are attempting to do some interop testing between a Broadsoft proxy,
and our SIP product which is acting as a B2BUA.  We are having issues
with the implementation of server redundancy in the Broadsoft
configuration.  According to their interop FAQ:

 

"BroadWorks uses a Geographic Redundancy model which requires DNS SRV to
support this mechanism.  The Primary Application Server (AS) will always
be the active server hosting the BroadWorks Users.   Call state is not
shared between the primary and secondary Application Servers.  If the
primary AS fails, the access device should send further sip requests to
the next SRV contact, secondary Application server.  When the primary
application server has failed, users will be migrated and hosted by the
secondary application server.  When the primary AS is restored, the
users hosted on the secondary AS will be migrated back to the primary
AS. 

If the DUT only supports DNS A records the device may experience
requests being toggled between primary and secondary Application
Servers.  If this happens, you'll need to create a local DNS with the
Application Server Cluster FQDN pointing to only the primary AS.

Note:  network devices (i.e., PSTN-terminating gateways and
softswitches) contact the BroadWorks Network Server (NS) cluster first
in a load-sharing manner.   The NS redirects to the appropriate AS.  The
network device must follow the DNS rules above for subsequent requests
to the AS within the dialog, using the FQDN contact supplied by the AS."

 

We do not support DNS in our product at this time.  The overall outcome
of this is that when we are sending an INVITE to start a new call, the
INVITE is sent to as.iop1.broadworks.net, which resolves to
64.215.212.70.  What we then observe is that we receive a 200 OK with
SDP, and a contact URI of <sip:as.iop1.broadworks.net>, whereupon our
SIP stack sends an ACK to this sip URI, but: this time it resolves to
64.215.212.71 and it seems like that server is not responding since it
never received the original INVITE.

 

Am I to understand that they expect all user agents (which is
essentially what our product is acting as) to implement DNS SRV in order
to properly interoperate with their proxy?  This seems silly to me (or
perhaps my understanding is too limited), because from my perspective,
DNS is a network-provided service and should not have to be built into
the end user client.

 

Thanks in advance for any information anyone can provide to help clear
up this issue.

 

 

Jeffrey D. Wright

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20071214/e08510f8/attachment-0002.html>