[SIPForum-discussion] Question regarding DNS SRV

[chintu]

Hi Jeff,Fernando

What I understood from Jeff's mail is " BroadWorks will migrate all the
connected users i.e those users are migrated whose Dialog is established.
And will not migrate those users whose deialog is not yet established ".

Here Dialog means  INVITE ------->
                             200 OK <-------
                             ACK ------------->
                                ( Primary Down )
                    Now this time only this user will be migrated......And
not whose ACK is not received.........


I might be wrong ..........


Regards,
Santosh.............



On 12/19/07, Fernando Lombardo <flombardo at novolink.net> wrote:
>
>  Is it possible that DNS is round-robin the A records that are part of the
> DNS SRV every time a query is made and thus your problem?
>
>  ------------------------------
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *Jeff Wright
> *Sent:* Friday, December 14, 2007 8: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*
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20071221/84cca41b/attachment-0002.html>