Subject: RE: [Sipping] 482 and draft-ietf-sipping-dialogusage-01

From: "Arunachalam Venkatraman \(arunvenk\)" <[email-masked]>
Date: Mon, 6 Mar 2006 10:16:21 -0800

I find this example intriguing.
Is it appropriate for A to make an assumption that cluster,example.com
represents a cluster of distinct alternate servers and not a single
multi-homed host?
The result will vary depending on this, would it not?

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 6:48 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]; 'sipping-ietf'
Subject: RE: [Sipping] 482 and draft-ietf-sipping-dialogusage-01

Trying again to explain the example...

A     P1     B
      P2

P1 and P2 represent a primary/secondary proxy cluster called
cluster.example.com.

A uses proxy P1 to call B.  P1 record-routes an FQDN
(cluster.example.com) representing p1.example.com and p2.example.com.
And the call gets fully established.

A wants to send a request over the dialog.  Resolving
cluster.example.com per rfc3263 produces an ordered list of locations to
try: P1 and P2.  A sends request to P1; and A gets no immediate
response.  A then sends the request to P2 early (without waiting the
full timer B or F); and soon receives a 482 because B detected the
merged request.

A received a 482 response from P2 and is still awaiting a final response
from P1; and the response (if it arrives) might be better than a 482.
Thus there is no reason to tear down upon receiving the 482 unless the
482 is the "best" response.

Including the following text again for reference.

> > Concerning the handling of 482, you discuss forking and merging.
> > 
> > For devices which "fork" early (before timer B or F) to next 
> > ip-address (list produced by rfc3263), it would be beneficial to 
> > include some additional text indicating that a better response might

> > still arrive on a prior branch still lacking a response.
> > 
> > The following threads are to refresh your memory about the situation

> > I am describing.
> > 
> > http://www1.ietf.org/mail-archive/web/sipping/current/msg07654.html
> > 
> > http://www1.ietf.org/mail-archive/web/sipping/current/msg07532.html
> > 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 6 Mar 2006 15:03:17 -0500

> Is it appropriate for A to make an assumption that 
> cluster,example.com represents a cluster of distinct 
> alternate servers and not a single multi-homed host? 

The sender does not necessarily know why the FQDN resolves to more than 1
IP-address.  However the sender knows that RFC 3261 and RFC 3263 allow for
it within a dialog and outside of a dialog.

> The result will vary depending on this, would it not?

Per RFC 3261 and RFC 3263, advancing to next IP-address can occur because of
errors, 503s, etcetera.  And it is typically up to the operators of the
devices (through configuration) to decide number and order of the
IP-addresses appropriate for the situation.