I think this scenario happens if all the RR headers that got added by proxies were FQDN's that resolved to multiple IP addresses (per section 16.6of 3261 this is possible, as the RR header MUST resolve to the IP address/port of this element that or a suitable stand in). On receipt of the 200 OK, the UA constructs the route set which is a set of FQDN's. It builds the ACK. It uses the Route set to send the ACK. This results in the UA having to do a DNS lookup. The response returned by DNS could result in the UA choosing an IP address/port of a proxy that is down. Venkatesh
On 6/16/05, Dale Worley <[EMAIL PROTECTED]> wrote: > > > From: Isaac Dudy > > > > Suppose UA sends INVITE to FQDN which is resolved to 2 different IP > > addresses. > > The UA tries the first IP, but there is no response since the > > server is > > down so the UA tries the second IP and succeeds (the UA got 2xx > > response). > > Now the UA has to send ACK but it MUST do resolving again. > > I believe that that statement is not correct. See para. 4 of section > 13.2.2.4 <http://13.2.2.4> of RFC 3261: "The header fields of the ACK are > constructed in the > same way as for any request sent within a dialog ..." In this case, it > would only be sensible if the ACK was sent using the route set established > by the INVITE/200. > > (I admit that para. 5 of that section contradicts my analysis: "Once the > ACK has been constructed, the procedures of [4][essentially, re-resolution > of the URI -- DRW] are used to determine the destination address, port and > transport." But following that rule contradicts para. 4 and leads to the > operational difficulties you described above.) > > Dale > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
