> Assume that a UAC is configured to use a DNS SRV FQDN to > contact a set of UAS (a primary and a secondary). Further > assume that the primary UAS is down (may be due to a restart > of the server). If the UAC sends a SIP request, it follows > the DNS SRV procedure and sends the request to the Primary > UAS first. Since the Primary UAS is down, the UAC fails over > to the Secondary UAS and gets challenged. > > Where should the UAC send the authenticated request first?
In my opinion, it is illogical to not try the successful location on the immediate resubmit (with higher CSeq) of a request based on 4xx-6xx responses. For primary/secondary configurations, not first trying the reached location likely adds extra traffic and likely adds extra time to get the request processed. For loadbalance configurations, not first trying the reached location could cause resubmit loops or all locations to be tried before finally providing authorization for a given nonce to the machine which challenged with the nonce. However if I understand RFC 3261 and RFC 3263 correctly, the primary would be tried first again (or loadbalance occurs again) unless a "local policy" is alternatively used. Thus you can apply a "local policy" to allow things to work more efficiently. Or you can act less efficiently and follow the default process. > Similarly, in the above scenario, if the request is INVITE > (and lets say doesn't get challenged); where should the UAC > send the ACK request first? RFC 3261 section 17.1.1.2 indicates the destination address and port of ACK for a non-2xx response MUST be identical to the INVITE. ACK for 2xx response follows the normal RFC 3263 process for the next hop within the dialog unless a "local policy" is used. If the ACK was for a re-INVITE, I suggest following a "local policy" if the successful location is still within the RFC3263 result list and sending to a proxy. I mention this because the ACK likely would not be able to really fork to the available location. Note: during dialog establishment if the secondary wants to become the primary within the dialog, it would be reflected by the next hop entry (resulting from Contact or Record-Route entry) within the dialog. Within a confirmed dialog, an endpoint can switch from being secondary to primary by supplying a new Contact. However proxies are unable to indicate such a switch after the dialog is confirmed. Thus applying a "local policy" instead of the default process can be more efficient. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
