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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 17:54:43 +0000

As below:

Keith 

> -----Original Message-----
> From: cuss [mailto:[email-masked]] On Behalf Of Atle Monrad
> Sent: 22 November 2013 19:04
> To: Gurbani, Vijay K (Vijay); [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay K. Gurbani
> Sent: 13. november 2013 20:11
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 16 Dec 2013 03:25:27 +0000

See below.

I will issue the version without the last two changes, but if the discussion identifies some other text with which the group agrees, a new version can always be issued.

Regards

Keith 

> From: cuss [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 28 November 2013 16:01
> Hello,
> Please find below some comments:
> 
> 1/ About "isdn-interwork" versus "isdn-uui" purpose parameter value: 
> 
> The discussions on the "[cuss] "isdn-uui" versus 
> "isdn-network"" email thread confirmed that there is still 
> support from other cuss participants for addressing the use 
> of the "isdn-network" parameter value. So, we don't think the 
> document can be published without addressing this issue. We 
> also understand that at least one company would not accept 
> replacing "RECOMMEND" with "MUST", so we propose to stick to 
> the initial approach (cf 
> http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm
> l ) and add the following text in section 11:
> 
> "The 'isdn-interwork' value for purpose parameter was used in 
> Internet-Drafts that have led to the publication of the 
> present RFC. Although these documents had no other status 
> than "work in progress", this value is implemented by some 
> vendors. Therefore, it is RECOMMENDED to support parsing and 
> interpreting 'isdn-interwork' the same way as 'isdn-uui' when 
> receiving."
> 
This one has been dealt with in a separate dialog, and the text agreed as a result of that dialog incorporated.

> 2/ About UAC and UAS procedures:
> 
> After having compared the UAC and UAS procedures in sections 
> 7 and 8, I noticed that 2 UAC procedures could be replicated 
> as UAS procedures as well, so I would suggest to add in section 7:
> "When receiving UUI, when a User-to-User header field is 
> received in a response that is not from the originating user 
> with the "purpose" header field parameter to "isdn-uui", or 
> with no "purpose" header field parameter, the UAS MUST 
> discard this header field."
> (this procedure seems not present for UAS)
> 
Section 7 is the UAC procedures, and therefore material will never be from the originating user.

This requirement was drafted because UUS1 in ISDN can only be originated from the originating user and therefore this is a unidirectional requirement.

Therefore I do not see the need for an equivalent procedure in clause 7.

> And to add in section 8:
> "When sending UUI for the ISDN package, if the "purpose" 
> header field is included, the UAS MUST set the User-to-User 
> "purpose" header field parameter to "isdn-uui"."
> (this procedure is present for UAS but not so explicitly written)
> 

Section 8 includes:

   The UAS MAY include the User-to-User header field in responses to the
   initial INVITE request, or the BYE requests or responses for the
   dialog, only where the original INVITE request included a User-to-
   User header field with the "purpose" header field parameter to "isdn-
   uui", or where no "purpose" header field parameter was included.
   When sending UUI for the ISDN package, the UAS SHOULD set the User-
   to-User "purpose" header field parameter to "isdn-uui".  Non-
   inclusion of the "purpose" header field parameter is permitted, but
   this is primarily to allow earlier implementations to support this
   package.  The UAS MUST NOT include more than one User-to-User header
   field for this package in any SIP request or response.

Does this not effectively say that.

> It could be worthwhile to add them in order to be symmetric 
> when a procedure is common to both UAC and UAS, otherwise 
> people could wonder if it means that they are just missing or 
> if it means that they are not applicable.
> 
> 
> We would like these 1/ and 2/ comments to be taken into 
> account before the ISDN draft becomes a RFC.
> Thank you in advance.
> 
> Best regards
> 
> Celine Serrut-Valette
> Orange Labs
> 
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Vijay K. Gurbani Envoyé : mercredi 13 novembre 
> 2013 20:11 À : [email-masked] Objet : [cuss] WGLC for 
> draft-ietf-cuss-sip-uui-isdn
> 
> ______________________________________________________________
> ___________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des 
> informations confidentielles ou privilegiees et ne doivent 
> donc pas etre diffuses, exploites ou copies sans 
> autorisation. Si vous avez recu ce message par erreur, 
> veuillez le signaler a l'expediteur et le detruire ainsi que 
> les pieces jointes. Les messages electroniques etant 
> susceptibles d'alteration, Orange decline toute 
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they 
> should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the 
> sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages 
> that have been modified, changed or falsified.
> Thank you.
>

---

From: <[email-masked]>
Date: Mon, 16 Dec 2013 14:57:28 +0000

Hello,

Thank you for the update of the ISDN draft.
I have just some comments or questions below on your answers to my previous comments:

1/ The text about "isdn-interwork" is in section 8 "UAS requirements" but it is also applicable to other sections, for instance to section 7 "UAC requirements" (when UAC receives UUI in responses), so could it be replicated in section 7 "UAC requirements" or only put once in section 11 "Coding requirements" in order to be global, as you prefer?
Note just an editorial comment: in section 16 about changes, "ISDNinterwork" purpose value should be replaced by "isdn-interwork".

2/A/ I agree with your comment on "originating user". But I think it would be better to clarify the expected behavior by UAS [respectively by UAC] on reception of User-to-User that is not with the "purpose" parameter to "isdn-uui", or with no "purpose" parameter, in a request [respectively in a response], as follows:  

"When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, the UAC MUST discard this header field." => this sentence of the draft is ok but "UAC" should be replaced by "UAS", isn't it? Because it's the UAS that receives the request containing UUI sent by UAC (same comment for sentences beginning by "When receiving UUI, when multiple User-to-User header [...]", it seems to me that "UAS" and "UAC" are inverted).

"When receiving UUI, when a User-to-User header field is received in a response that is not with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, the UAC MUST discard this header field." => this sentence could be added in order to specify the UAC behavior when it receives unexpected UUI in a response from the UAS.

2/B/ Yes the sentence "When sending UUI for the ISDN package, the UAS SHOULD set the User-to-User "purpose" header field parameter to "isdn-uui".  Non-inclusion of the "purpose" [...]" is well present in both sections 7 and 8. 
But the sentence "When sending UUI for the ISDN package, if the "purpose" header field is included, the UAC MUST set the User-to-User "purpose" header field parameter to "isdn-uui"." is only present in section 7 but not in section 8, why? (first sentence aims at recommending to include a purpose parameter using a SHOULD whereas second sentence clarifies the required value using a MUST)  

Thank you for your clarifications.

Best regards
 
Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:[email-masked]] 
Envoyé : lundi 16 décembre 2013 04:25
À : SERRUT VALETTE Celine IMT/OLN; Gurbani, Vijay K (Vijay); [email-masked]
Objet : RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

See below.

Regards

Keith 

> The discussions on the "[cuss] "isdn-uui" versus "isdn-network"" email 
> thread confirmed that there is still support from other cuss 
> participants for addressing the use of the "isdn-network" parameter 
> value. So, we don't think the document can be published without 
> addressing this issue. We also understand that at least one company 
> would not accept replacing "RECOMMEND" with "MUST", so we propose to 
> stick to the initial approach (cf 
> Internet-Drafts that have led to the publication of the present RFC. 
> Although these documents had no other status than "work in progress", 
> this value is implemented by some vendors. Therefore, it is 
> RECOMMENDED to support parsing and interpreting 'isdn-interwork' the 
> same way as 'isdn-uui' when receiving."
> 

> 7 and 8, I noticed that 2 UAC procedures could be replicated as UAS 
> procedures as well, so I would suggest to add in section 7:
> "When receiving UUI, when a User-to-User header field is received in a 
> response that is not from the originating user with the "purpose" 
> header field parameter to "isdn-uui", or with no "purpose" header 
> field parameter, the UAS MUST discard this header field."

> header field is included, the UAS MUST set the User-to-User "purpose" 
> header field parameter to "isdn-uui"."

Section 8 includes:

> It could be worthwhile to add them in order to be symmetric when a 
> procedure is common to both UAC and UAS, otherwise people could wonder 
> if it means that they are just missing or if it means that they are 
> not applicable.
> 
> 
> We would like these 1/ and 2/ comments to be taken into account before 
> the ISDN draft becomes a RFC.
> Thank you in advance.
> 
> Best regards
> 
> Celine Serrut-Valette
> Orange Labs
> 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Vijay K. Gurbani Envoyé : mercredi 13 novembre
> Folks: Enrico and I will like to announce a WGLC for the ISDN draft 
> [1].
> 
> 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.
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
> 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.