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

From: Adam Roach <[email-masked]>
Date: Wed, 3 Sep 2003 15:58:06 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Sep 2003 08:11:22 +0100

Adam,

Thanks for reviewing this document. Please see my responses in-line.

John ([email-masked])

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: 03 September 2003 21:58
> To: [email-masked]'
> Subject: [Sipping] Comments on draft-ietf-sipping-qsig2sip-02
> 
> 
Although the name QSIG arose because it was signalling at the Q reference
point, this expansion is not normally used. Also the "Q reference point"
would then need explaining. I prefer to leave it alone.

>     the description here is correct?
For T1 it should be 23, not 24. I will change it.

>     that *all* SIP 100-class responses are optional in practice.
The QSIG ALERTING and PROGRESS messages can be accompanied by in-band
information. If SDP offer has been received in the INVITE request, the
gateway can return SDP answer in the 18x response and play media. If no SDP
offer has been received in the INVITE request, the SDP offer needs to be
sent in the 18x response in order to get an answer in a PRACK and be able to
play the media.

>     seems contrary to what is described here.
I believe you are correct, in which case a simplification can be made to the
handling of 18x.

>     responses, not 200 responses.
The penultimate paragraph covers receipt of 2xx other than 200, so I believe
2xx is covered.

>     dialogs so created are to be torn down with a BYE.
OK

>     is probably best to remove this note to avoid undue confusion.
OK

>     paragraph of this section is a bit confusing.
This is a hang-over from earlier text. It should talk about any 4xx, 5xx or
6xx response.

>     SIP message can be assumed to be complete.
The SIP network could be used for bridging dissimilar networks, e.g., a call
from ISUP via SIP to QSIG. The ISUP network could use overlap sending, and
if this is not absorbed at the ISUP/SIP gateway it will be received at the
SIP/QSIG gateway. Encapsulation of legacy signalling messages is not
feasible in this sort of situation.
Even between two QSIG networks, if the QSIG/SIP gateway is unaware of
possible egress from SIP back to QSIG or doesn't support encapsulation of
QSIG, it may use overlap.

>     calls, or to simply have his calls fail?
See earlier response. The text has recently been changed so that only a
gateway is obliged to support 100rel and can choose to proceed with a call
from a UAC that does not support 100rel. I don't think it therefore
introduces interoperability problems, but it does mean that in order to
comply with this specification a SIP/QSIG gateway must support 100rel.

>     and could best be considered a summary, not a specification.
What in particular do you consider to be missing? Since the previous draft
this has been rewritten as a result of other comments received and I believe
it is now a concise yet sufficient specification of required behaviour.

>     you describe. 488 has the meaning that I think you're trying
OK

>     until this issue is adequately addressed.

RFC3398 does not specify authentication. It mentions it only in the context
of authenticating the sender of encapsulated ISUP, which doesn't apply to
the QSIG draft. Any use of authentication can use standard SIP procedures
and will not have direct impact on QSIG signalling.

>     information" in a SIP network, I think this needs to be
That line should have been struck out.

>     addresses a single security concern.
This text is taken from RFC3398 and adapted - also shortened slightly
because it doesn't need to deal with encapsulation. Otherwise I would agree
with you, but for consistency with 3398 I prefer to leave it as it is.

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Sep 2003 17:30:11 -0500

A few responses inline.

/a

> From: Elwell, John [mailto:[email-masked]]
> 
> Although the name QSIG arose because it was signaling at the 
> Q reference

Okay. As a warning, the RFC editor will almost certainly comment
on this issue as well.

> The penultimate paragraph covers receipt of 2xx other than 

Generally, I have concerns about potential for misinterpretation
if "200" is called out when "2xx" is meant. I've seen far too
many implementations fail to handle non-200, but still 2xx-class,
responses correctly.

> SIP/QSIG gateway. Encapsulation of legacy signaling messages is not

Okay. That makes sense. Perhaps a sentence or two to this effect
in the draft would be warranted.

> QSIG, it may use overlap.

I'm confused. I thought the document explicitly said that QSIG->SIP->QSIG
bridging is out of scope.

> The text has recently been changed so 
> that only a
> from a UAC that does not support 100rel.

That makes more sense. I'd still be much happier with a SHOULD or
MUST than a MAY, though. Failing to setup a call because you
can't provide an ideal user experience is very shortsighted. Barring
physical harm, there is no less ideal user experience than a system
that does not work.

> it is now a concise yet sufficient specification of required 

- Callflows. 

- A more detailed description of canceling pending
  INVITE transactions. 

- A description of the proxy routing issues discussed in
  section 3.1 of RFC 3578.

- A discussion of CANCEL behavior with overlap dialing.

- A discussion of handling of early media with overlap dialing.

- Probably others. You would be best off copying and adapting
  RFC 3578.

> and will not have direct impact on QSIG signaling.

3398 is part of a larger framework established by RFC 3372.
Because of the precise issues I described earlier about
trusting data for injection into the PSTN (or, in your case,
PISN) network, it has normative statements such as:

   SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and
   SHOULD support encryption (CMS EnvelopedData).

My primary point is that the current QSIG draft discusses
P-Asserted-Identity to the exclusion of any other security mechanisms.

> with you, but for consistency with 3398 I prefer to leave it as it is.

As I said, it's simply a stylistic comment -- so, while I don't agree
with your rationale, I'm not going to argue about it.

/a

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 10 Sep 2003 16:12:22 -0700

> Okay. As a warning, the RFC editor will almost certainly 
> comment on this issue as well.

It's confusing, but John is right: QSIG doens't actually stand for 
anything anymore. It's not an acronymn. 

> That makes more sense. I'd still be much happier with a 
> SHOULD or MUST than a MAY, though. Failing to setup a call 
> because you can't provide an ideal user experience is very 
> shortsighted. Barring physical harm, there is no less ideal 
> user experience than a system that does not work.

I tend to agree with Adam on this one. My opinion is that the
text should explain that support for 100rel is recommended, along
with an explanation of why.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Sep 2003 21:41:13 +0100

Adam,

In-line

.... 
> many implementations fail to handle non-200, but still 2xx-class,
I still don't understand what change you would like to see. Would it help if
I put 200 and 2xx excluding 200 into separate sub-sections?

....

> bridging is out of scope.
No it does not say that. In section 5, 5th paragraph it says that
encapsulation of QSIG signalling in SIP messages is outside the scope. I
will clarify it to indicate that there is nothing to prevent bridging
between two QSIG networks or two parts of the same QSIG network by complying
with this specification (without encapsulation) at each gateway.

> physical harm, there is no less ideal user experience than a system
Will go for SHOULD, in line with Francois' suggestion.

> > it is now a concise yet sufficient specification of required 
See figure 8.

> - A more detailed description of canceling pending
This is inappropriate for 8.3.9, which is dealing with SIP to QSIG. For the
other direction, I believe 8.2.2.2.9 and 8.2.2.2.5 deal with cancel
adequately.

> - A description of the proxy routing issues discussed in
8.2.2.2 makes reference to the principles described in RFC3578.

> - A discussion of CANCEL behavior with overlap dialing.
See above.

> - A discussion of handling of early media with overlap dialing.
8.2.2.2.8 references 3.3 of RFC3578, which deals with this.

> - Probably others. You would be best off copying and adapting
The draft makes several references to RFC3578 in accordance with advice from
one of the chairs. The intention was to avoid duplicating too much of
RFC3578. Note that reference [18] will be changed from the overlap draft to
RFC3578 at the next draft.

>    SHOULD support encryption (CMS EnvelopedData).
This is because SIP-T encapsulates ISUP messages in MIME. Because we are not
covering QSIG encapsulation in this specification, then S/MIME is not
relevant.
...

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Sep 2003 18:41:18 -0500

> I put 200 and 2xx excluding 200 into separate sub-sections?

No, you're missing the point. If your gateway receives a 
"273 Well, I Guess So" response, that needs to map to a CONNECT,
unless the gateway has some better idea about what "273" means
as a response. Any non-recognized 200-class response is treated
as a 200 (cf. RFC 3261, section 8.1.3.2).

So, the change I'd like to see is for this single section to never
say "200" except as part of the phrase "200-class," and to remove
any text that implies that unrecognized responses from 201 to 299
don't set up the session. Specifically:

    8.2.1.4 Receipt of SIP 2xx response 
         
        If the gateway receives a SIP 200-class response as the first SIP 
        200-class response to a SIP INVITE request, the gateway SHALL map
        the SIP 200-class response to a QSIG CONNECT message. The gateway
        SHALL also send a SIP ACK request to acknowledge the 200-class
        response. The gateway SHALL NOT include any SDP information in the
        SIP ACK request. If the gateway receives further 200-class
responses,
        it SHALL respond to each in accordance with [10] and SHALL NOT
        generate any further QSIG messages. 
         
        Media streams will normally have been established in the IP network 
        in each direction. If so, the gateway SHALL connect the media
streams 
        to the corresponding user-information channel on the inter-PINX link

        if it has not already done so and stop any local ring-back tone. 
         
        If the SIP 200-class response is received in response to the SIP
PRACK 
        request, the gateway SHALL NOT map this message to any QSIG message.

        NOTE. A SIP 200-class response can be received later as a result of
a 
        forking proxy. 

----

Aside from that, the rest of your responses are okay with me,
save the issue of authentication. Basically, what it comes down
to, I believe, is equal time. If you mention P-Asserted-Identity,
mention Digest, S/MIME, and TLS as well. If you want to remove
reference to specific mechanisms and simply indicate that SIP has
mechanisms to provide the necessary authentication properties,
that's fine with me also.

What concerns me is that the document currently emphasizes a
non-recommended authentication mechanism to the exclusion of
others.

/a