[Sipping] Comments on draft-ietf-sipping-qsig2sip-02

[Adam Roach <[e-mail]>]

In Vienna, I volunteered to review the QSIG/SIP mapping
draft (draft-ietf-sipping-qsig2sip-02). My comments follow.
Note that I am not a QSIG expert, and have not reviewed
the QSIG procedures in this document for accuracy.

Abstract:
  - Expand QSIG as "Q Reference Point Signaling (QSIG)"

Section 5:

  - Admittedly, my knowledge in this area is a bit rusty,
    but if you channelize a T1, you get 24 channels only
    if you use CAS; however, if this is the model being
    deployed, an E1 would have 32 channels, not 30. With
    QSIG, it is my understanding that, for a typical deployment,
    a T1 would have 23 channels (plus a D channel for
    signaling), while an E1 would have 30 channels (plus one
    for timing and another for signaling). Are you certain
    the description here is correct?

Section 7:

  - Why is 100rel mandatory? I mean, it's *nice*, but I
    don't see how it is required for QSIG interwork. Remember
    that *all* SIP 100-class responses are optional in practice.

Section 8.2.1:

  - In the NOTE, you should include "receipt of Sending
    Complete" as a method of determining that the number
    is complete.

Section 8.2.1.3:

  - No SDP answer is strictly necessary for media to be
    sent towards the caller. Is there a reason this specification
    seems to require it? In fact, 3261 requires that you be
    ready to receive media after sending an INVITE, which
    seems contrary to what is described here.

Section 8.2.1.4:

  - This behavior should be defined in terms of 200-class
    responses, not 200 responses.

  - Description of handling of additional 200-class responses
    should be better detailed. I suggest specifying that the
    dialogs so created are to be torn down with a BYE.

Section 8.2.2.2.2:

       "NOTE 3. The first SIP INVITE request and all subsequent SIP INVITE 
        requests sent in this way belong to the same call but to different 
        dialogs."

  - This is a bit confusing. RFC 3261 has no formal definition
    of the term "call" (it defines it as an informal term). It
    is probably best to remove this note to avoid undue confusion.

Section 8.2.2.2.7:

  - The mention of the 484 response code in the third
    paragraph of this section is a bit confusing.

Section 8.3.1:

  - I was under the impression that PISN bridging using
    SIP is out of scope. In particular, section 5 says:

       "Another way of migrating is to use a SIP network to interconnect two

        parts of a PISN and encapsulate QSIG signaling in SIP messages for 
        calls between the two parts of the PISN. This is outside the scope
of 
        this specification but could be the subject of future work."

    I would think that any discussion of handling overlap
    dialing originating in the SIP network seems inappropriate.
    Currently, the only overlap procedures defined in SIP apply
    only when the SIP network is used for bridging similar networks.
    In other words, I would argue that receipt of a number in a
    SIP message can be assumed to be complete.

  - Once again, requiring 100rel is merely going to artificially
    introduce interoperability problems. This needs to be
    removed. Consider: is it better to have a user miss
    PISN-generated ringback but still be able to make
    calls, or to simply have his calls fail?

Section 8.3.9:

  - See first comment under section 8.3.1. Note also that
    this behavior is very underspecified. Note that the
    specification of this behavior for ISUP (RFC 3578) is 
    several pages long. This section is shorter than one page,
    and could best be considered a summary, not a specification.

Section 8.5:

  - I believe that 503 is inappropriate for the circumstance
    you describe. 488 has the meaning that I think you're trying
    to convey here.

Section 9.2:

  - This section and its subsections ignore any mechanism
    that SIP terminals might use to authenticate themselves
    with the gateway. As the most trivial example, gateways
    can challenge terminals to provide credentials (using
    Digest authentication) and derive trust of the "From"
    field accordingly. Additional mechanisms such as the use
    of mutual TLS certificates and S/MIME (e.g.
    draft-ietf-sip-authid-body-02) can be similarly applied
    for authentication purposes.

    This shortcoming is a *major* hole in the current document.
    I *seriously* doubt it will pass muster with the IESG
    until this issue is adequately addressed.

Section 10.2:

  - I might have just missed it, but how does one actually
    make use of a "data" session on the SIP side of things?
    This needs significantly more specification than a single
    line mapping the media type in SDP to "data". Is this
    using TCP? Comedia? RTP? UDP? If UDP, is there retransmission?
    Unless there's some specification you can cite or write
    that describes how to transit PISN "unrestricted digital
    information" in a SIP network, I think this needs to be
    removed.

Section 11:

  - As a stylistic suggestion, I would recommend splitting
    this section into several subsections, each of which
    addresses a single security concern.

Appendix A:

  - As in section 11, I would suggest splitting each example
    callflow into a separate subsection.

  - As discussed above, I believe that Figures 8 and 9 and their
    descriptions need to be removed.

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP