Subject: [SIP] My comments on bis-02

From: Billy Biggs <[email-masked]>
Date: Mon, 30 Oct 2000 22:48:08 -0600

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.

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.

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.

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?

   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.

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.

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.

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?

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.

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

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

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