G'day

I have reviewed the draft again and have a couple of nits.

1.
Abstract

   The motivation and use cases for interworking and transporting ITU-T
   DSS1 User-user information element data in SIP are described in the
   "Problem Statement and Requirements for Transporting User to User
   Call Control Information in SIP" document.  As networks move to SIP
   it is important that applications requiring this data can continue to
   function in SIP networks as well as the ability to interwork with
   this ISDN service for end-to- end transparency.

Remove space:   this ISDN service for end-to-end transparency.

2.
3.2.  Impacts of the ISDN service on SIP operation

   The ISDN service has the following impacts that need to be understood
   within the SIP environment.

   Call transfer  ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.

   Conference  ISDN conferencing allows the user to still exchange user-
      to-user data after the conference is created.  As far as UUS1 is
      concerned, it is not permitted.

      The ISDN three-party supplementary service is similar in many ways
      to conferencing, but is signalled using a different mechanism.
      This means that on clearing, the controller using UUS1 implicit
      does have the choice of sending data to either or both remote
      users.  Because SIP conferencing cannot completely emulate the
      ISDN three-party supplementary service at the served user, UUS1
      implicit is not possible.

   Diversion  When ISDN diversion occurs, any UUS1 user-to-user data is
      sent to the forwarded-to-user (assuming that the call meets
      requirements for providing the service - this is impacted by the
      explicit service only).  If the type of diversion is such that the
      call is also delivered to the forwarding user, they will also
      receive any UUS1 user-to-user data.

Would it make sense to add some NLs and/or :s after the three "ISDN SSs" to split the text and improve readability??

e.g. like
   Call transfer:
      ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.
Or
   Call transfer:  ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.

----
I hope the draft can progress soon

Cheers
/atle

________________________________ 


Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson



-----Original Message-----
From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vijay K. Gurbani
Sent: 13. november 2013 20:11
To: cuss@ietf.org
Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Folks: Enrico and I will like to announce a WGLC for the ISDN draft [1].

The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013.

We will appreciate your comments on the draft, posted to the list.  All comments are appreciated, even if it is a simple one-liner saying that you believe the draft is ready, or conversely, that it is not ready (and why).

As you review the draft, as part of your WGLC review, please identify any issues that may exist in regard to compatibility with draft-ietf-cuss-uui (the mechanism draft).

Thank you.

[1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/

Vijay K. Gurbani and Enrico Marocco
_______________________________________________
cuss mailing list
cuss@ietf.org
https://www.ietf.org/mailman/listinfo/cuss