> On 15 Mar 2016, at 13:38, Brett Tate <br...@broadsoft.com> wrote: > > Hi, > >>> As far as I know, the main complaint is that it can >>> temporarily prevent/delay honoring the DNS configured load >>> balancing and priorities. >> >> So there is a consensus that transaction based DNS load >> balancing is more preferable to the dialog based TCP >> connection reuse? Meaning that is preferred to have >> initial INVITE over proxy1, call hold reINVITE over proxy2 >> and BYE over proxy 3 having three TCP connections for one >> dialog. > > I'm not sure that I'd call it consensus; however the default behavior is > as you describe if that is what the RFC 3263 resolution causes. > > The inability to change the Record-Route entry is one reason why some > vendors don't follow the default behavior. For instance if you advance a > mid-dialog request to secondary because primary is down, the secondary > can't update the Record-Route entry so that it becomes the primary. Thus > unless the device improves the algorithm, it can cause additional delays > within the dialog because of the need to advance (although it is less of > an issue with TCP). > > For completeness... sipcore is currently working on > draft-ietf-sipcore-dns-dual-stack which updates RFC 3263.
Just a side note: This is one problem SIP Outbound doesn’t handle. We’ve had discussions about how to handle failover during a dialog or even during a transaction. There’s some words in RFC 3263 about this - if I remember correctly it’s about routing on DNS names in Via headers forcing a DNS SRV lookup. /O
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
