> > If SRV records not supported, the Contact should 
> > reflect a single AS
> 
> Did you mean that if SRV records ARE supported?

Hi Attila,

Nope.  If SRV supported and being used, the SRV records allow the desired order 
to be clearly indicated.


> Isn't the problem that the Contact in the 2xx didn't 
> contain something that maps to a single device?

Depends upon intent.

I assume that the person configuring the Contact had reason to supply a Contact 
able to resolve to more than 1 location.  I assume the reason is that the 
alternative location can occasionally (obviously not always because question 
posted) be able to handle the in-dialog requests.  If the alternative location 
can never handle the in-dialog requests, I agree that it would be an 
inappropriate configuration.

Cheers,
Brett


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Brett Tate
> Sent: 20 May 2008 13: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).
> 
_______________________________________________
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

Reply via email to