Subject: [Sipping] 482 mid usage

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Feb 2005 15:09:05 -0600

I don't think I've received any comment on this from dialog-usage-00:

482 Loop Detected:
This response is aberrant mid-dialog. It will only occur if
the Record-Route header field was improperly constructed by
the proxies involved in setting up the dialog's initial usage,
or if a mid-dialog request forks and merges (which should never
happen). Future requests using this dialog state will also
fail. The dialog and any usages sharing it are destroyed.
OPEN ISSUE: This response may have been triggered by method
(and perhaps usage) specific handling. Is destroying the
entire dialog too severe?

Unless I hear otherwise, -01 will remove this open issue and
stick with the resolution that the dialog and any usages are
destroyed.

RjS

_______________________________________________
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: Thu, 3 Feb 2005 14:02:21 -0500

> 482 Loop Detected:
> This response is aberrant mid-dialog. It will 
> only occur if the Record-Route header field 
> was improperly constructed by the proxies 
> involved in setting up the dialog's initial 
> usage, or if a mid-dialog request forks and 
> merges (which should never happen).

A device which forks within a dialog might receive 482 for a merged request.
The device would need to correlate the responses/timeouts to decide what
should occur.  The 482 might trigger resending a request on prior branch or
waiting a little longer on prior branch.

> Future requests using this dialog state will 
> also fail. The dialog and any usages sharing 
> it are destroyed. OPEN ISSUE: This response 
> may have been triggered by method (and perhaps 
> usage) specific handling. Is destroying the 

If the device did not fork and receives a 482, destroying the dialog might
not be too severe.  However if a device forks and chooses to tear down the
dialog when a 482 response was received on 1 branch and no response was
received on another branch, I think that the BYE request (or related dialog
termination mechanism) should be sent.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 3 Feb 2005 13:13:15 -0600

inline

>> merges (which should never happen).

So - before we start building mechanism around things that
fork in dialog can we establish that this is a case worth considering?
As I note above, this should _never happen_. It's another of those
things that if it happens, enough of the system is broken that 
specifying
behavior probably won't make sense.

Given that, I  think we shouldn't burden the specs with more language
covering how to respond to the case.

Are we seeing forked mid-dialog requests in the real world?
I'm not aware of any...

> not be too severe.
I'm becoming more convinced that it is exactly the right thing to do.

>   However if a device forks and chooses to tear down the

RjS

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 3 Feb 2005 14:45:02 -0500

> So - before we start building mechanism 
> around things that fork in dialog can 
> we establish that this is a case worth 
> considering? As I note above, this 
> should _never happen_.  It's another 
> of those things that if it happens, 
> enough of the system is broken that 
> specifying behavior probably won't make sense.

The frequency depends upon the chosen interval for the forking mechanism.
If the chosen forking interval is small (1 - 2 seconds), it could be
frequent when dealing with slower devices or flaky networks.

> Are we seeing forked mid-dialog requests 

Yes.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 3 Feb 2005 15:17:41 -0600

> frequent when dealing with slower devices or flaky networks.

Huh? I have no idea what you're talking about here.
Mid-dialog, there is no forking mechanism.

>> Are we seeing forked mid-dialog requests

Please describe the scenario where you're seeing it then.

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 3 Feb 2005 17:11:21 -0500

> Mid-dialog, there is no forking mechanism.

If device provides a Contact or Record-Route entry which resolves to more
than 1 address, forking can occur within the dialog.  If the device supports
forking within a dialog, the forking occurs based upon timers (retry
exhaustion) and 503 per the usual forking and dns resolutions of rfc3261 and
rfc3263.

> Please describe the scenario where you're seeing it then.

Dialog established between A and B.  B provided Contact entry with hostname
that resolves to B and B'.

If A supports forking within a dialog and B does not respond within a
reasonable interval or returns 503, A can fork within the dialog to send the
request to B'.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Feb 2005 09:45:42 -0600

I think I see what you're trying to describe, and it takes us into 
another area
where the specifications aren't particularly well developed (and we're 
trying
to address some of it in -nit-future, though it applies to INVITE 
transactions
as well as NITs).

Here's the kind of scenario I think you're describing:
----
You have a proxy cluster with two proxies, P1 and P2. You have 
provisioned
DNS such that pcluster.example.com points to P1 and P2 with equal 
weights
(using two SRV RRs). P1 and P2 are sharing sufficient state to act on 
each
other's behalf at any time (bold statement).

UA1 enters into an INVITE usage with UA2. It just happens to select P1, 
which
record-routes with <pcluster.example.com>.

UA1 sends a re-INVITE through P1, but doesn't get any response at all,
timer B fires, and you roll to the second SRV record and send the 
request
using the same CSeq but a different branch id to P2, which dutifully 
completes
the transaction (assume a 200). Meanwhile, P1 wakes up (nothing was 
dead,
it was just slow)  and spits out the request. UA2 482s what it got from 
P1.
----

UA1 acted like a forking proxy in this case. From your comments, I 
suspect
you're not waiting for timer B, (or F for non-INVITEs), but have your 
own
timer after which you break into forking proxy behavior.

The thing is, once UA1 forks like this, either based on timer B or its 
own
non-standard timers) it has to follow _ALL_ the rules of a forking 
proxy,
which means keeping a response context around and selecting the "best"
final response to send upstream (which in this case is to the local 
application).
For our original question, if a 482 is the "best" response from the 
context,
then the current conclusion in the draft is still the right one - 
things have
gone wrong and the usage should go away. In the simple scenario above,
that won't happen since the best response was the 200 that went to the
app immediately.

I suspect we need to explicitly discuss this behavior in a spec and 
point
out what the ramifications are for an endpoint that chooses to behave
this way. We also should note that an endpoint isn't trapped into 
becoming
a forking proxy by 3263 - in the example above, it has the option of 
considering
the entire transaction that didn't get a timely response from P1 over 
and using
the next CSeq to talk through P2.

RjS

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 11 Feb 2005 10:45:02 -0600

Robert Sparks wrote:
> another area where the specifications aren't particularly well 
> developed (and we're trying to address some of it in -nit-future, 
> though it applies to INVITE transactions as well as NITs).
> 
> You have a proxy cluster with two proxies, P1 and P2. 

Robert:

There is another corner case, albeit one that can be handled in the
same way (i.e., by following _ALL_ rules of a forking proxy).

The corner case is as follows: consider a UAC (or the proxy-half of
a UAC) that wants to send a request downstream.  The UAC supports
UDP and TCP transports.  Absent any transport indicator in the
downstream URI (let's say it was a FQDN and a DNS A lookup
succeeded), the UAC tries TCP first and then UDP.  Let's also
assume that the downstream entity is unable to receive requests
over TCP (it is a rfc2543-compliant UA).  In this case, a second
branch will be tried over UDP, which will succeed and either
return a 2xx or a non-2xx.  In case of a non-2xx, as long as
the UAC follows the rules of forking and keeps separate response
contexts for each branch, things work out fine (although care
must be taken in implementing the software to NOT generate a
CANCEL on the TCP branch when a 2xx or 6xx is seen; but this is
an implementation issue).

Strictly speaking, though, I wonder if what we are discussing
is forking?  I view finding P1 or P2 from a proxy cluster
or the example above as a server location process (a la rfc3263).
To me, forking implies the act of targetting a request to _different_
_targets_, i.e., the R-URI is different (along with the branch id).
But this may degenerate into a pedantic discussion, so I don't
necessarily want to harp on this.  The resolution to this general
problem is the same; namely, maintain a response context as a
forking proxy does and, absent a 200 OK, choose the best response.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 11 Feb 2005 13:31:13 -0500

> The corner case is as follows: consider a UAC 
> (or the proxy-half of a UAC) that wants to 
> send a request downstream. The UAC supports 
> UDP and TCP transports.  Absent any 
> transport indicator in the downstream URI 
> (let's say it was a FQDN and a DNS A lookup 
> succeeded), the UAC tries TCP first and then UDP.

Forking between transports based upon DNS queries (or lack of NAPTR and SRV
entries) was made obsolete by RFC3261 and RFC3263.  Forking across
transports because of large messages does exist (rfc3261 section 18.1.1).
However if the UAC only performs the transport fallback to udp based upon
the error conditions mentioned in 18.1.1, I doubt a response would really be
received on both transports.

http://www1.ietf.org/mail-archive/web/sip/current/msg10425.html

http://bugs.sipit.net/show_bug.cgi?id=760

<snip>

> The resolution to this general problem is 
> the same; namely, maintain a response context 
> as a forking proxy does and, absent a 200 OK, 
> choose the best response.

I agree.