Subject: RE: [SIP] My comments on bis-02

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 7 Nov 2000 15:23:41 -0000

> 2. In 4.2.5, it is noted that CANCEL requests cannot have Route headers.
>    Why not?  Are you assuming that CANCEL is only useful for an initial
>    request?  This breaks since we need to be able to CANCEL a pending
>    REFER or other extension method which doesn't complete quickly, for
>    example.

I doubt that the thinking here is CANCEL is only useful for an
initial request, more that there is no need to specify a Route
since proxies will always "know" which locations to cancel in
turn; CANCEL is not forwarded like other requests, thus a Route
is not necessary.

 - Jo.

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 24 Nov 2000 16:41:43 -0500

An updated version of -02 (to be submitted) is at the
www.cs.columbia.edu/sip location. I would appreciate if you could check
which of your remarks still apply. In terms of "fluff", the only way to
forward progress is if folks specifically identify redundant wording.
I'm all for shortening the spec, but not if it means that you have to
read FAQs, papers and mailing lists to start working on the
implementation.

Thanks for the comments.

Billy Biggs wrote:
> 
>   These are some of my (late) issues with bis-02.  BTW, It would help
> for commenting on the draft if there was a text file version.
> 
> Comments which may require discussion
> -------------------------------------
> 
> 1. In 4.2.1 there is discussion about how to handle INVITEs which cross
>    on the wire.  Are you worried about when two endpoints change their
>    contact address at the same time?  If you're just worried about the
>    session changing, it seems that it would be more
>    interoperability-friendly if implementations just re-re-INVITE'd when
>    they believe requests may have crossed, and use some internal random
>    timer.

This has been discussed a few times on the list, but may need to be
rolled up again.

>    REFER or other extension method which doesn't complete quickly, for

Removed.

> 3. Sections 6.25 and 10.1.1 (maybe others), as I mentioned in another
>    post to the list, imply that clients should choose a single local tag
>    and preserve this across calls.  This is a bad idea in cases when UAs
>    call themselves, may lead to UAs choosing the same tag value in some
>    cases, and also poses a security risk.
> 
>    I strongly recommend that the recommendation change to be that tags
>    should always be unique.  Apologies to those implementations that
>    want to try and preserve calls over reboots.  I don't see much point
>    to section 11.5 either.  Using the same tag doesn't solve all the
>    problems, so why bother trying?  It just makes things confusing and
>    prone to failure.

Obviously, separate discussion. Clarified as indicated in my email for
now.

> 
> 4. Regarding Authentication in 13.2, is it the responsibility of the
>    UAC to not use short form headers after the Authorization, or is it
>    the responsibility of the proxy to switch them when transforming the
>    message into canonical form?

Text says "Clients wishing to authenticate requests ... no short form
header fields". I'm not sure what's ambiguous here.

> 
>    I ask because there are extensions to SIP which propose new short
>    forms for headers that proxies will not know about.  An example of
>    this is the REFER draft.  Should the UAC not use these short forms,
>    or should extensions not propose them?
> 
> 5. Due to the proliferation of the Also header in BYE requests, I would
>    suggest that it be added to the bis draft, with its meaning
>    restricted to use with the BYE method.

Tentatively added.

> 
> 6. Mid-Call redirects.  The wording for the 305 response code seems to
>    indicate that it can be sent mid-call.  This breaks if you have a
>    Route.  I guess the only reasonable thing to do is say that if you
>    get redirected mid-call you should drop your route?  Or even better,
>    tell UAs that they cannot send a redirect response to a request with
>    a To tag?  Regardless, the bis draft should mention this case.

Any mid-call INVITE can return a 3xx. I can't see why 305 is special in
this regard. This does not necessarily mean that the route is bad, as
the Contact will just be added to the bottom. Yes, future requests may
travel strange hairpin paths, but, with care, a proxy can recuse itself
out of route.

> 
> 7. See my last post regarding the scope of the Call-ID.
> 
> Comments which are just bugs
> ----------------------------
> 
> 8. It would be nice in section 16 if all of the examples included from
>    tags.  As well, Figures 1 and 2 don't have tags.

Figure fixed; tags added.

> 
> 9. Section 4.2.6 explicitly mentions that REGISTER messages can be
>    redirected.  This seems redundant.  I also believe that there are
>    other areas of the spec where it is quite verbose and redundant.
>    While this is to the benefit of new readers in some cases, the draft
>    is also now quite large.  Can we maybe try and strip some of the
>    fluff out?

Section removed. Other suggestions welcome.

> 
> 10. Section 1.4.6 says Call-ID when it means "within the same call leg".
> 
> 11. In section 7.4.1, as was noted somewhere, "Missing Content-Length
>     header" is a bad example unless it is now mandatory.

Changed to Missing Call-ID header
> 
> 12. Section 1.4.2 implies that clients do not need to support UDP.  I
>     think this is a bug.
> 

Please see if this is still a problem.

> --
> Billy Biggs, 3Com               Email: [email-masked]
> http://www.div8.net/billy/      Phone: [email-masked]

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Mon, 27 Nov 2000 00:29:52 -0600

Henning G. Schulzrinne ([email-masked]):

> www.cs.columbia.edu/sip location. I would appreciate if you could
> check which of your remarks still apply.

  Many thanks.  I will give more detailed comments soon.

> > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route
> >    headers.  Why not?  Are you assuming that CANCEL is only useful
> >    for an initial request?  This breaks since we need to be able to
> >    CANCEL a pending REFER or other extension method which doesn't
> >    complete quickly, for example.
> 
> Removed.

  I think I was wrong on this one.  CANCEL is of hop-by-hop significance
within a transaction and doesn't use the Route.  Stateful proxies
instead remember and the UA sends the CANCEL just to the first entry in
the Route.

> > 6. Mid-Call redirects.  The wording for the 305 response code seems
> >    to indicate that it can be sent mid-call.  This breaks if you
> >    have a Route.  I guess the only reasonable thing to do is say
> >    that if you get redirected mid-call you should drop your route?
> >    Or even better, tell UAs that they cannot send a redirect
> >    response to a request with a To tag?  Regardless, the bis draft
> >    should mention this case.
> 
> Any mid-call INVITE can return a 3xx. I can't see why 305 is special
> in this regard. This does not necessarily mean that the route is bad,
> as the Contact will just be added to the bottom. Yes, future requests
> may travel strange hairpin paths, but, with care, a proxy can recuse
> itself out of route.

  I don't see how proxies can recuse themselves out of the Route.  It
has come up before on this list: once the Route is setup it may not be
modified, only the Contact at the end may change.

  Thank you for clarifying the meaning of a mid-call redirect.  Time to
fix code.

> > 12. Section 1.4.2 implies that clients do not need to support UDP.
> >     I think this is a bug.
> 

  The text currently is:

  "If no protocol is specified, the client tries UDP (if UDP is
   supported).  If the attempt fails, or the client doesn't support UDP
   but supports other protocols, it tries those protocols in some
   unspecified order."

  This implies that clients do not need to support UDP.  I thought UDP
was a requirement, but it looks like it's only a SHOULD for clients.
MUST is only used in the section on a minimal implementation.