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. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
