Subject: RE: [SIP] Questions on new loop detection mentioned in RFC2543 bis

From: [email-masked]
Date: Tue, 18 Jul 2000 13:59:42 -0500

My comments with >>>>

"Jo Hornsby" <[email-masked]> on 07/18/2000 11:05:16 AM

Sent by:  "Jo Hornsby" <[email-masked]>

To:   Anoop Tripathi/MW/US/3Com, [email-masked]
cc:
Subject:  RE: [SIP] Questions on new loop detection mentioned in RFC2543 bis

> I have some questions on how we distinguish the BYE and CANCEL
> messages for a call in case a proxy is now twice in the path
> of the same call. (Note:In RFC 2543 bis with the new loop
> detection mechanism it is now possible for a Proxy to be present
> twice in the path of the same call if the Request-URI is
> different.)
>
> Assuming that a proxy P2 is now twice in the path of the call.
>
> The scenario is as follows
>
>
> A---------------P1------------P2----/
> ------P3----------P2---------P4----------B.
>
>
> I assume that P2 would treat them as two different calls.
>
> 1)  P1-----P2------P3
>
> 2) P3-----P2------P4

Yup.  The requests are different because of the different
Request-URI.

> Q1)  Now when a CANCEL message comes to P2, the only way it can
> find out whether it is from P1 or P3 is if the Request-URI in
> CANCEL IS SAME AS IN INVITE.
> Are we guaranteed to have the Request-URI in these two messages
> the same?

Yup.  I've lost it in the draft, though. &:(

> Q2)  If P2 is call stateful, then it needs to put some additonal
> tags in the Record-Route header, similar to hash values it has
> put in Via header to distinguish BYE     messages?

Putting any sort of state or ID or whathaveyou in Record-Route
is no good because by the time a new request has arrived at
the offending proxy, the pertinent Route value has been popped.

But you have raised a very good point, I feel.  Since Record-Route
is defined to be (basically) name-addr plus an maddr parameter,
it is probably workable if clients copy the addr-spec component
of the topmost Route value into the Request-URI (which is what
they are supposed to do), and send it to the address specified
by the maddr parameter; _provided_ that a proxy copied the
Request-URI of the initial request into the Record-Route, and
added its own IP as the maddr parameter (not so sure this is
conforming -- I am a little confused by the second paragraph of
6.35.1 in the July bis).

This has a couple of problems, though:
 1) In the reverse direction; i.e., if UA1 initially called
    UA2 resulting in a spiral through a Proxy which added
    itself twice in the Record-Route, and then UA2 issues a
    re-INVITE to UA1; it (illegally) loops.  This is because of
    the rules about constructing the Route header in 6.35.2,
    which say that the Contact address of UA1 will be used as
    the name-addr part.
 2) Proxies are going to have to accept that Record-Routes
    need to go though port 5060 (or perhaps some other returned
    by SRV), since there is no way to specify otherwise with maddr.
    (This problem isn't restricted to this special case, however,
    since the "reverse" request path, for instance, exhibits
    the same problems.)

> Q3)         Can a call leg still be identified with CallID, From
> and To headers or we need one extra identifier ( probably a hash
> similar to one in Via) ?

Well, I guess if you need to keep tabs on both parts of the spiral,
you could use the Request-URI.
>>>> How does it route the BYE from the called party. What should a Request URI
from B contain?
I think the easiest solution is probably to just note that the
request has spiralled, and update state for the multiple interested
"parties" as necessary.  Is there any need for a proxy to add
itself more than once in a Record-Route?  There can still only be
one call leg, after all.
>>>> We cannot assume that because to add to it P3 could have forked the
request. So while P2 sent out one
>>>> to P3, P3 forked it and now P2 is in the path a forked request. Hence we
cannot assume one call leg.
>>>>> The bottom line is CallID, From and To alone are not sufficient  to
identify a call leg once we >>>>> allow this new loop detection
HTH,

 - Jo.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 19 Jul 2000 10:38:11 +0100

> >>>> How does it route the BYE from the called party. What should 
>      a Request URI from B contain?

According to the spec, the Request-URI from B should contain
the contact address of A.  The Request-URI will contain the
contact address of A at every point along the path, in fact,
which is why we result in an illegal loop.

> >>>> We cannot assume that because to add to it P3 could have
>      forked the request. So while P2 sent out one
> >>>> to P3, P3 forked it and now P2 is in the path a forked
>      request. Hence we cannot assume one call leg.

I was being naiieve, but it's still not a problem.  Consider
the following two scenarios:

[1]         
                            +--------- P4
                            |           |
                            |           |
                            |           |
                            |           |
                            |           |
    A -------- P1 -------- P2 -------- P3
                            |
                            |
                            |
                            |
                            |
                            B

[2]
                            +--------- P4
                            |           |
                            |           |
                            |           |
                            |           |
                            |           |
    A -------- P1 -------- P2 -------- P3 -------- C
                            |
                            |
                            |
                            |
                            |
                            B

In case [1], the request has spiralled through P2, and the
initial INVITE results in one call leg, A<->B.

In case [2], the request has spiralled through P2, and the
initial INVITE results in two call legs, A<->B and A<->C.

In both cases, P2 can easily detect that the result has
spiralled, by looking for a match on the From, To, Call-ID, CSeq,
and ignoring the Request-URI.  Therefore, it only adds itself
to the Record-Route list the first time it sees the request
(from P1).

If the request has forked at any point, then P2 will just have
multiple To "tags" to keep track of.

Finally, if P2 needs to know that it saw the request spiral
at some point, and needs both Request-URIs, all it needs to
do is to associate some extra state with it's state on the
call-leg(s).  The call-state has to apply at both points by
implication.

> >>>>> The bottom line is CallID, From and To alone are not
>       sufficient to identify a call leg once we
> >>>>> allow this new loop detection

Call-leg is defined in terms of endpoints -- proxies just
may happen to sit along the path.  Therefore, it doesn't
matter if the Request-URI has been changed X times, and
spiralled Y times -- the notion of call-state is going to be
the same wherever.

HTH,

 - Jo.