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

From: "Brett Tate" <[email-masked]>
Date: Fri, 3 Mar 2006 16:34:09 -0500

Hey Robert,

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

Thanks,
Brett

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Mar 2006 17:21:28 -0500

I'm not sure this belongs in this particular draft.

The fact that one can fork, and this get both multiple dialogs and 
multiple dialog usages is nothing new, and is well understood by those 
that care enough to understand. The forking case can never occur for 
shared dialogs, though the dialog can become shared after the forking 
occurs.

So I think these are orthogonal issues.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 3 Mar 2006 18:02:54 -0500

> I'm not sure this belongs in this particular draft.

I am referring to same device sending a request to multiple ip-addresses
within the dialog (ip-address list produced by rfc3263).  This is mainly for
the primary/secondary type situation Robert and I discuss within the
mentioned threads.  Robert does a good job of clarifying the situation in
the following thread.

I know some don't like calling the trying of multiple ip-address per rfc3263
forking.  That was why I put it in quotes.  However since the same device
changes the Via branch when sending to multiple locations, it sounds
extremely similar to forking to me.  When it occurs within the dialog, I
typically refer to it as "forking within the dialog"; does anybody have a
better name for it?  Forking-the-rfc3263-list?

> > 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.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Mar 2006 18:41:29 -0500

> mentioned threads.  Robert does a good job of clarifying the situation in

Ah. At least that isn't what I thought you were talking about.

> forking. 

I don't know what to call it. But it is similar enough to (serial) 
forking that I will let you call it that in some contexts. (Not that you 
needed my permission.)

> That was why I put it in quotes.  However since the same device

I don't see how you can say this is occuring "with the dialog". When it 
occurs a dialog has yet to be established. The caller has something 
amounting to a "half dialog" (a callid and from-tag) but you also need 
the to-tag to have a dialog. (Maybe its a "two-thirds-dialog" since two 
of the three parts are present.)

IMO the UAS first has a dialog when it sends a response containing a 
to-tag. (Even if the response isn't reliable.) But it doesn't yet know 
if the UAC is aware of the dialog.

The UAC first has a dialog when it receives a response (reliable or not) 
containing a to-tag.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 3 Mar 2006 19:47:37 -0500

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Mar 2006 23:06:12 -0500

OK Brett, that is a case I hadn't thought about. Now that I see what you 
are talking about I am really reluctant to call it forking. I guess what 
you describe is valid. (You really do this - trying another path before 
the earlier path fails???)

Sure, certainly doesn't hurt to acknowledge these this possibility.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 6 Mar 2006 13:46:48 -0500

> OK Brett, that is a case I hadn't thought about. 
> Now that I see what you are talking about I am really 
> reluctant to call it forking.

> (You really do this - trying another path before 

Some vendors allow various things to be configurable for capacity,
reliability, and service reasons.  This can include configuration of the
number of retries, configuration of the SIP letter timers, configuration of
maximum addresses to try, and configuration of suspicion thresholds similar
to RFC2705.

Because users tend to dislike 32 second delays and things like ICMP errors
are not always sent or they are blocked, some operators prefer the advancing
occur prior to 32 seconds.

One benefit of suspicion thresholds is that it allows advancing while still
allowing the prior branch to succeed (when needed).

> Sure, certainly doesn't hurt to acknowledge this possibility.

Thanks.