The provided section 12.2.1.1 quote is from the UAC subsection of "Requests within a Dialog" section. Please reread the two quotes.
-brett > -----Original Message----- > From: DING Derrick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 21, 2008 10:00 PM > To: Brett Tate > Cc: [email protected] > Subject: RE: [Sip] SIP one DNS domain much IP > > > But you can see, what the guy described is in a dialog > instead of "outside of a dialog". > Please point out if I don't understand correctly. > > Thanks > > Derrick > > -----Original Message----- > From: Brett Tate [mailto:[EMAIL PROTECTED] > Sent: 2008年5月21日 21:41 > To: DING Derrick > Cc: [email protected] > Subject: RE: [Sip] SIP one DNS domain much IP > > Your understanding corresponds to a "local policy" overriding > the rules of following RFC 3263. Your mentioned "local > policy" has not been presented within an RFC. > > RFC 3261 section 12.2.1.1: "Once the request has been > constructed, the address of the server is computed and the > request is sent, using the same procedures for requests > outside of a dialog (Section 8.1.2)." > > RFC 3261 section 8.1.2: "The destination for the request is > then computed. Unless there is local policy specifying > otherwise, the destination MUST be determined by applying the > DNS procedures described in [4] as follows." > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > > DING Derrick > > Sent: Tuesday, May 20, 2008 9:50 PM > > To: Brett Tate; 孙永光; [email protected] > > Subject: Re: [Sip] SIP one DNS domain much IP > > > > As my understanding, A should not do DNS query without any > exception, > > such as 408 timeout. > > > > So you should define the condition for DNS query in order > to avoid the > > case you describe. > > > > Derrick > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > > Brett Tate > > Sent: 2008年5月20日 20:42 > > To: 孙永光; [email protected] > > Subject: Re: [Sip] SIP one DNS domain much IP > > > > Because of potential load-balancing (as you are observing), solely > > using A records within primary/secondary configurations should be > > avoided unless additional agreements or configuration has > been made to > > avoid the situation you are describing concerning in dialog > requests. > > The additional agreements override typical rfc3263 behavior by > > applying local policy (potentially non compliant) to remain > stateful > > within dialog. The potential additional configuration (to > avoid the > > mentioned override) is to have DNS control to avoid automatic > > load-balancing/iterating concerning A records so that the A record > > query/handling can always result in the same ordered list. > > > > RFC 3263 discusses using DNS SRV records to more clearly indicate > > prioritization and load-balancing. If SRV records not > supported, the > > Contact should reflect a single AS unless the alternative locations > > can accommodate the situation (or additional agreements or > > configuration has been made to avoid trying the alternative > locations > > first). > > > > > > ________________________________ > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of ??? > > Sent: Tuesday, May 20, 2008 7:11 AM > > To: [email protected]; IETF Sipping List > > Subject: [Sip] SIP one DNS domain much IP > > > > > > > > Hi Guys: > > > > I have a question about DNS > > it is that one DNS domain has much IP Addrs , eg: > > as.test.net=>(192.168.2.1/192.168.2.2) > > and "as.test.net: is B2B server > > 1) A INVITE B , A resolves the DNS "as.test.net" > > 192.168.2.1,then A sends INVITE request to > > 192.168.2.1 > > 2) A receives 200 response with contact "as.test.net" > > and no record route > > 3)A resolves the DNS "as.test.net" again, it gets > > 192.16.2.2 and sends ACK to 192.168.2.2 > > > > now the 192.16.2.1 can't recieve the ACK request , so > the session > > can't be created > > > > Anyone can give me any advice, or some RFC/draft about it > > > > Thanks in advance > > > > Samman > > 2008-5-20 > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
