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

["Elwell, John" <[e-mail]>]

Adam,

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

John ([e-mail])


> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]] 
> Sent: 03 September 2003 21:58
> To: '[e-mail]'
> Subject: [Sipping] Comments on draft-ietf-sipping-qsig2sip-02
> 
> 
> 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)"
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.

> 
> 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?
For T1 it should be 23, not 24. I will change it.

> 
> 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.
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.

> 
> 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.
I believe you are correct, in which case a simplification can be made to the
handling of 18x.

> 
> Section 8.2.1.4:
> 
>   - This behavior should be defined in terms of 200-class
>     responses, not 200 responses.
The penultimate paragraph covers receipt of 2xx other than 200, so I believe
2xx is covered.

> 
>   - 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.
OK

> 
> 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.
OK

> 
> Section 8.2.2.2.7:
> 
>   - The mention of the 484 response code in the third
>     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.

> 
> 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.
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.

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

> 
> 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.
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.

> 
> 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.
OK

> 
> 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.

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.


> 
> 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.
That line should have been struck out.

> 
> Section 11:
> 
>   - As a stylistic suggestion, I would recommend splitting
>     this section into several subsections, each of which
>     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.

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

_______________________________________________
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