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

From: [email-masked]
Date: Tue, 18 Jul 2000 09:55:56 -0500

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

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?

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?

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) ?

Thanks,

Anoop Tripathi

3COM

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 18 Jul 2000 17:05:16 +0100

> 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.)
> 
> A---------------P1------------P2----/
> ------P3----------P2---------P4----------B.
> 
> 

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.

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.

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.

HTH,

 - Jo.