Subject: Re: [Sip] SIP one DNS domain much IP

From: "DING Derrick" <[email-masked]>
Date: Thu, 22 May 2008 09:59:38 +0800

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-masked]] 
Sent: 2008年5月21日 21:41
To: DING Derrick
Cc: [email-masked]
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-masked] [mailto:[email-masked]] On 
> Behalf Of DING Derrick
> Sent: Tuesday, May 20, 2008 9:50 PM
> To: Brett Tate; 孙永光; [email-masked]
> 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-masked] [mailto:[email-masked]] On 
> Behalf Of Brett Tate
> Sent: 2008年5月20日 20:42
> To: 孙永光; [email-masked]
> 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-masked] 
> [mailto:[email-masked]] On Behalf Of ???
> 	Sent: Tuesday, May 20, 2008 7:11 AM
> 	To: [email-masked]; 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 22 May 2008 08:31:40 -0400

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

> From: DING Derrick [mailto:[email-masked]] 
> Sent: Wednesday, May 21, 2008 10:00 PM
> To: Brett Tate
> Cc: [email-masked]
> 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."
> 
> 
> Behalf Of 
> > DING Derrick
> > So you should define the condition for DNS query in order 
> to avoid the 
> > case you describe.
> > 
> > Derrick
> > 
> Behalf Of 
> > Brett Tate
> > 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 
> 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).
> > 
> >