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

From: "Attila Sipos" <[email-masked]>
Date: Tue, 20 May 2008 15:16:22 +0100

Hi Brett,

Thanks for your response - to me it highlights something
that I don't understand in RFC 3263:

   Because the ACK request for 2xx responses to INVITE constitutes a
   different transaction, there is no requirement that it be delivered
   to the same server that received the original request (indeed, if
   that server did not record-route, it will not get the ACK).

So if it doesn't get the ACK, the 2xx response will be retransmitted
over and over - won't it?

This is what I don't understand - under what condition is it desired
that the 2xx ACK goes to a different destination than the original INVITE?

Cheers,
Attila

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: 20 May 2008 14:34
To: Attila Sipos; 孙永光; [email-masked]
Subject: RE: [Sip] SIP one DNS domain much IP

> > 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-masked] [mailto:[email-masked]] On Behalf Of 
> Brett Tate
> Sent: 20 May 2008 13: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).
> 

.
_______________________________________________
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: Tue, 20 May 2008 13:44:58 -0400

> So if it doesn't get the ACK, the 2xx response 
> will be retransmitted over and over - won't it?

It depends upon how "redundant" the cluster actually is.  If fully redundant, an ACK or PRACK received on one server can stop response retries on the other.  

Similarly rfc3263 section 5, allows responses to "forked" upon failure to deliver.  If a proxy/UAC truly that redundant, a response received on one server can stop request retries on the other.

> This is what I don't understand - under what 
> condition is it desired that the 2xx ACK goes 
> to a different destination than the original INVITE?

Concerning ACK and PRACK, usually never unless truly that flexible.  Concerning other requests, it may or may not prefer it but might allow it.