Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

["DRAGE, Keith (Keith)" <[e-mail]>]

As below:

Keith 

> -----Original Message-----
> From: cuss [mailto:[e-mail]] On Behalf Of Atle Monrad
> Sent: 22 November 2013 19:04
> To: Gurbani, Vijay K (Vijay); [e-mail]
> Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn
> 
> 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.
> 
Done - seems to be something xml2rfc does that I was not expecting - hopefully changed the source so it does not happen.

> 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've added the colon. New lines is beyond my xml2rfc capabilities.

> ----
> 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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Vijay K. Gurbani
> Sent: 13. november 2013 20:11
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cuss
> _______________________________________________
> cuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cuss
>