Subject: "Legal" via loops

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 01 Dec 1999 22:22:03 +0000

I believe that this has been discussed in the past, but I don't believe
there was a resolution.

It reframe the problem, assume user A invites user B at proxy 1.  User B
redirects the call to User C at proxy 2 and user C redirects the call to
user D at proxy 1.

User A            Proxy 1           Proxy 2
----------------->
Invite B@P1
V: A
F: UserA@A
T: UserB@P1
I: 1234@A
Cseq: 1 INVITE
                  ----------------->
                  Invite C@P2
                  V: P1
                  V: A
                  F: UserA@A
                  T: UserB@P1
                  I: 1234@A
                  Cseq: 1 INVITE
                  <-----------------
                  Invite D@P1
                  V: P2
                  V: P1
                  V: A
                  F: UserA@A
                  T: UserB@P1
                  I: 1234@A
                  Cseq: 1 INVITE

At this point, proxy 1 will reject the call with a 482 Loop Detected.  This
is despite the fact that it is a new request for a different request URI.
It just happens that two users in the path of the INVITE are served by the
same proxy.

Am I correct that no resolution to this problem has been proposed?

Steve

P.S. We have some ideas on how to address this, but first I want to make
sure that  I haven't missed an already proposed solution.

P.P.S There is a second level problem lurking for stateful proxies, even if
we solve the via loop issue.  This is due to the fact that a stateful proxy
that does not detect this as a via loop will detect it as a retransmission
(same call leg (to, from, callid) with the same cseq and probably drop the
invite.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Dec 1999 01:37:21 -0500

Yes, this is a problem. We have discussed it in the past, and I don't
think there was an agreed upon solution.

I believe the solution to this that is backwards compatible is to make
use of the branch ID parameter in the Via field. Let me explain.

At a proxy, we say that a request is a new transaction (not a
retransmission, and not a loop), if its Call-ID, To, From CSeq *and*
request URI are different from another request. In that case, we can
define a transaction ID as a hash over these quantities. Call this hash
H. Also assume that a proxy is set up so that if it forks, it never
forks more than 2**N times, for some N that is sufficiently large. When
a proxy forks, the ith branch has a branchid parameter with the value (H
<< N) + i. 

When a response arrives, the proxy takes the branch ID parameter from
the top Via field, shifts it right by N, and obains the transaction ID.
This allows the response to be matched to the request. The N bits that
were shifted out identify which branch the response is for.

To do loop detection, when a request arrives, the proxy looks for its
own address in the Via list. If it finds it, AND if the branch ID
parameter in that Via field, shifted right N bits, match the transaction
ID computed for this request, it is considered a loop. Otherwise, if the
proxy doesn't find its address in the Via list, but the transaction ID
computed from the request matches the transaction ID of an existing
transaction, its a retransmission. Otherwise, its a request for a new
transaction.

There are other ways to place both the actual branch ID, and this new
hash, into the branch ID parameter in the Via field, besides this shift
by N.

Comments?

-Jonathan R.

> "Donovan, Steven R." wrote:
> 
> I believe that this has been discussed in the past, but I don't
> believe there was a resolution.
> 
> It reframe the problem, assume user A invites user B at proxy 1.  User
> B redirects the call to User C at proxy 2 and user C redirects the
> call to user D at proxy 1.
> 
> User A            Proxy 1           Proxy 2
> ----------------->
> Invite B@P1
> V: A
> F: UserA@A
> T: UserB@P1
> I: 1234@A
> Cseq: 1 INVITE
>                   ----------------->
>                   Invite C@P2
>                   V: P1
>                   V: A
>                   F: UserA@A
>                   T: UserB@P1
>                   I: 1234@A
>                   Cseq: 1 INVITE
>                   <-----------------
>                   Invite D@P1
>                   V: P2
>                   V: P1
>                   V: A
>                   F: UserA@A
>                   T: UserB@P1
>                   I: 1234@A
>                   Cseq: 1 INVITE
> 
> At this point, proxy 1 will reject the call with a 482 Loop Detected.
> This is despite the fact that it is a new request for a different
> request URI.  It just happens that two users in the path of the INVITE
> are served by the same proxy.
> 
> P.S. We have some ideas on how to address this, but first I want to
> make sure that  I haven't missed an already proposed solution.
> 
> P.P.S There is a second level problem lurking for stateful proxies,
> even if we solve the via loop issue.  This is due to the fact that a
> stateful proxy that does not detect this as a via loop will detect it
> as a retransmission (same call leg (to, from, callid) with the same
> cseq and probably drop the invite.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 2 Dec 1999 10:49:45 -0500

On first blush, it appears this will work. Another approach that may be
simpler is to allow a VIA to be marked explicitly as a "loop-barrier", so
that any proxy doing loop detect does not look further back in the VIA list
than the first "loop-barrier". Any stateful proxy that intercepts responses
and re-issues INVITES would mark its VIA with a loop-barrier.

This seems simpler than Jonathan's proposal but may have backward
compatibility problems. OTOH, existing proxies will falsely detect loops no
matter what we do, right?

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Thursday, December 02, 1999 1:37 AM
> To: Donovan, Steven R.
> Cc: [email-masked]
> Subject: Re: "Legal" via loops
>
>