Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Feb 2012 03:17:50 +0100

My comments below indicating my proposed handing. I'll take this as I'ved indicated for the next draft unless I see alternative proposals or objections from members of the working group in the next 5 days or so.

Suggest if commenting to these that those items agreed with are removed.

If I've missed anything do please let me know.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 05 January 2012 17:04
> To: [email-masked]
> Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway
> 
> Hello and Happy New Year,
> 
> Please find our comments on draft-ietf-cuss-sip-uui-isdn-01:
> 
> **Section 3.1**
> C1: "to control the request and granting of the service, as in USS2 and
> UUS3" => just an editorial comment, "USS2" should be replaced by "UUS2".
> 
OK

> C2: "Only a single user information package can be transported in each
> message" => in order to avoid any misunderstanding, it would be clearer to
> indicate that this restriction concerns "isdn-uui" package, so it would be
> in-line with section 6 where this precision is given and with section 5
> where another package could be used (enhanced package) in parallel with
> "isdn-uui". Otherwise, without this clarification, it could be understood
> as no other package is allowed.
> Proposal: "Only a single user information package set to "isdn-uui" can be
> transported in each message".

This sentence is talking about the ISDN service and how that works and its constraints, where there is no package concept. The sentence predates the use of the term "package" as part of the protocol and I guess it would be better to remove the term here to avoid confusion. I think just removing the word works best: "Only a single user information can be transported in each message."

> 
> **Section 5**
> C3: "the endpoint can carry the UUI data both as ISDN and as some other
> package in parallel" => it would be suitable to explicitly indicate that
> ISDN UUI and other types of UUI using other packages are conveyed either
> in the same or in different messages.
> 
> 
> Proposal: "the endpoint can carry the UUI data both as ISDN UUI and as
> other types of UUI defined in other packages, in parallel in the same or
> in different messages".

I propose adding "depending on the needs of the application" (after same or in different), otherwise I propose to follow the proposal here.

> 
> **Section 7**
> C4: "The UAC MUST only use this package of the UUI mechanism extension in
> association with the initial INVITE method and the BYE method relating to
> an INVITE dialog. Usage on transactions associated with any other type of
> dialog, or on methods not associated with a dialog is precluded." => The
> first sentence indicates that User-to-User header can only be conveyed in
> initial INVITE request, its responses, BYE request and its responses
> (which is consistent with the definition of UUS1) whereas the scope of the
> second sentence is wider because it means that other methods within the
> INVITE-initiated dialog (e.g. UPDATE) can be used to convey UUI, although
> only initial INVITE and BYE methods are allowed.
> Proposal: "The UAC MUST only use this package [...]. Usage on transactions
> associated with any other type of dialog, or on methods not associated
> with a dialog, or on methods related to an INVITE dialog but different
> from initial INVITE or BYE methods is precluded."
> 
I propose to follow this, except to make the proposal a separate sentence: "Usage on other methods within the INVITE dialog, and on re-INVITE transactions with the INVITE dialog, is also precluded."

> C5: "If the UAC wishes to user or permit the sending of UUI data at any
> point in the dialog, the UAC MUST include in the INVITE request for that
> dialog a User-to-User header field with an "package" header field
> parameter set to "isdn-uui". This initial header field constitutes the
> implicit request to use the UUI service, and is therefore included even
> when there is no data except the protocol discriminator octet to send at
> that point in time." => the use of User-to-User header even with no uui
> data in INVITE request for implicit request should be a possibility but
> not a requirement since the uui option tag has been created for that
> purpose and allows as well to declare and negotiate the uui capacity.
> Proposal: replace "MUST" by "MAY" in the above sentences.
> 
I guess when I wrote the above requirement, I was working on what I understood the uui mechanism draft would say, because at that time it was not available. So we need to evaluate what we need to say.

I agree that based on the current mechanism draft, on receipt without a "package" header field parameter "uui-isdn" has to be assumed.

For sending, I believe an explicit indication would at least be good practice. I also believe it would be confusing if for example a media feature tag indicating "sip.uui-isdn" was included but a package header field parameter was not.

Would changing the "MUST" to a "SHOULD be an appropriate solution", along with some additional clarification.

I would propose the text as follows:

" If the UAC wishes to use or permit the sending of UUI data at any point in the dialog, the UAC MUST include in the INVITE request for that dialog a User-to-User header field. The UAC SHOULD set the "package" header field parameter to "isdn-uui". Non-inclusion of the "package" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package. This initial header field constitutes the implicit request to use the UUI service, and is therefore included even when there is no data except the protocol discriminator octet to send at that point in time."

This is also going to result in a number of changes where reception of the "package" field is specified, to encompass the non-inclusion with the same meaning, I propose not to elaborate these here.

> C6: "The UAC MUST NOT include the User-to-User header field with an
> "package" header field parameter set to "isdn-uui" in any message of an
> INVITE dialog if the original INVITE request did not include the User-to-
> User header field with an "package" header field parameter set to "isdn-
> uui".") => it should be allowed to include a User-to-User header even if
> no User-to-User header was present in INVITE request since the negotiation
> of the uui capacity can be done by uui option tag instead.
> Proposal: replace "MUST" by "MAY" in the above sentence.

I think "MAY" is the wrong solution to this comment. If there is an entirely different "package" header field parameter, continuing to assume this is "isdn-uui" would be inappropriate.

Propose rewording to:

" The UAC MUST NOT include the User-to-User header field with an "package" header field parameter set to "isdn-uui", or with no "package" header field parameter", in any message of an INVITE dialog if the original INVITE request did not include the User-to-User header field, either with an "package" header field parameter set to "isdn-uui", or with no "package" header field parameter included."

> 
> C7: "Because for the ISDN UUI service, the service is service 1 implicit,
> the inclusion of the "uui" option tag in a Supported header field conveys
> no additional information over and above the presence of the User-to-User
> header field with the "package" header field parameter to "isdn-uui" in
> the INVITE request. While there is no harm in including the "uui" option
> tag, and strictly it should be included if the extension is supported, it
> performs no function" => it should be possible, in order to
> declare/negotiate the uui capability, to use the uui option tag instead of
> the inclusion of User-to-User header even with no uui data, at least by
> indicating both possibilities.
> Proposal: "While there is no harm in including the "uui" option tag, and
> strictly it should be included if the extension is supported, it performs
> no function when User-to-User header is included in INVITE request for
> implicit request. Otherwise, the uui option tag is used to indicate that a
> UA supports and understands the User-to-User header field."
> 
I believe this comment is incorrect.

While this would work in the absence of ISDN interworking, if ISDN interworking was involved they there would be an extra complication to the interworking. In ISDN it is the presence of the user-to-user information parameter / information element in ISDN IAM / DSS1 SETUP message that indicates the request for the service. That is why it is called implicit. The presence of data implicitly requests the service.

If we follow the proposal above, we effectively give the gateway two alternates to map an empty user-user received from ISDN, and have to deal with both those alternatives when received in SIP at the gateway.

Moreover, in the ISDN there is no such thing as an empty user user, as it still has to contain the protocol discriminator. I quote for example Q.957.1: " Service 1 may be implicitly requested by including a User-to-user information element of variable length as specified in 4.5/Q.931 [1] in the SETUP message, transferred across the user network interface at the calling side as described in 5.1.1/Q.931 [1]. This information element is transported by the network and delivered unchanged in the User-to-user information element included in the SETUP message transferred across the user network interface at the called side as described in 5.2.1/Q.931 [1]. For activation purposes, this information element must be at least three octets long, as defined in 4.5/Q.931 [1]."

There are requirements elsewhere in the i-d to include the protocol discriminator as the minimum contents of the uuidata.

> C8: "When sending UUI for the ISDN package, the UAS MUST set the User-to-
> User "package" header field parameter to "isdn-uui" and "When receiving
> UUI, when a User-to-User header field is received in a request that is not
> from the originating user with the "package" header field parameter to
> "isdn-uui", the UAC MUST discard this header fields." => this requires the
> presence of package parameter (with value set to "isdn-uui"). In order to
> be consistent with draft-ietf-cuss-sip-uui-04 ("If the "package" parameter
> is not present, interworking with the ISDN UUI Service MUST be assumed"),
> it would be necessary to add that when package parameter is not present,
> its default value "isdn-uui" must be assumed.
> Proposal (in reception): "When receiving UUI, when a User-to-User header
> field is received in a request that is not from the originating user with
> the "package" header field parameter to "isdn-uui", the UAC MUST discard
> this header fields. When receiving UUI, if no package header field
> parameter is present, the UAC must assume its default value "isdn-uui"".
> Proposal (in emission): "When sending UUI for the ISDN package, if the UAS
> includes a User-to-User "package" header field parameter, it MUST set it
> to "isdn-uui".
> 
Does the following work?:

" When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "package" header field parameter to "isdn-uui", or with no "package" header field parameter, the UAC MUST discard this header field."

This is one of the many changes to encompass the non-receipt of the header field parameter.

> C9: As done in Section 8 for UAS, it would be relevant to indicate the
> behavior of the UAC when a User-to-User header field is received in a
> response that is not with the "package" header field parameter to "isdn-
> uui" (discarded?).
> 
> **Section 8**
> C4, C6 and C8 comments are also applicable in this section.
> 

I will address in accordance with any agreement on the comments above.

> **Section 13**
> C10: "This document adds the following row to the "UUI packages" sub-
> registry of the SIP parameter registry: Value: isdn-uui" => it would be
> suitable to rename the value of package parameter from "isdn-uui" into
> "isdn-interwork". The goal would to allow compatibility with already
> deployed implementations that are based on the draft-johnston individual
> draft (draft referenced since a long time in 3GPP documents). There would
> be no change regarding the meaning because the definitions of "isdn-
> interwork" and "isdn-uui" values are exactly the same, for ISDN
> interworking scenarios ("which is to interoperate with ISDN User to User
> Signaling (UUS)").
> 

This is driven directly from the mechanism draft, so I will follow whatever it states there.

> Regards,
> 
> Celine Serrut-Valette
> Orange Labs
> 
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Vijay K. Gurbani
> Envoyé : jeudi 15 décembre 2011 17:15
> À : [email-masked]
> Objet : [cuss] Expert review of sip-uui-isdn draft underway
> 
> Folks: Celine Serrutvalette has agreed to perform an expert review of
> the UUI ISDN draft (thanks, Celine).
> 
> The expert review is due Jan-10-2012.
> 
> The token for a second expert review of the SIP mechanism draft is
> with Martin Dolly.
> 
> I suspect that once both these expert reviews are in, Enrico and I
> will ask the editors to modify their respective drafts and proceed
> to WGLC.
> 
> Until then, y'all have a nice holiday season.
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [email-masked]
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> 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: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 23 Feb 2012 18:11:00 +0100

Dear Keith, Celine,

You wrote

> > "package" header field parameter set to "isdn-uui" in any message of 
> > an INVITE dialog if the original INVITE request did not include the 
> > User-to- User header field with an "package" header field parameter 
> > set to "isdn-
> > uui".") => it should be allowed to include a User-to-User header even 
> > if no User-to-User header was present in INVITE request since the 
> > negotiation of the uui capacity can be done by uui option tag instead.
> I think "MAY" is the wrong solution to this comment. If there is an entirely different "package" header
> field parameter, continuing to assume this is "isdn-uui" would be inappropriate.
>
> Propose rewording to:
>
> " The UAC MUST NOT include the User-to-User header field with an "package" header field parameter
>  set to "isdn-uui", or with no "package" header field parameter", in any message of an INVITE dialog
>  if the original INVITE request did not include the User-to-User header field, either with an "package"
>  header field parameter set to "isdn-uui", or with no "package" header field parameter included."

In my understanding the scope of this draft is UUS1 implicit.
We should thus aim to have comparable behavior to the ISUP service.
In my understanding (based on Q.737.1, quotation below) of ISUP UUS1 implicit, UUS can be included in an ISUP response even if none was in the IAM.

If I am correct, neither the original wording nor the proposed rewording of Keith allows for a proper interworking of the service. We should rather also allow "isdn-uui" within a User-to-User header in SIP responses irrespective of what was contained in the SIP request. 

FYI I paste in the text from Q.737.1 I deem relevant:

1.1.5.2.1.1.3 Transfer of user-to-user information
User-to-user information may be contained in any of the messages that may be transferred in the call
set-up and call release phases, independently of whether the service is requested implicitly or
explicitly, provided that the explicit service 1 has not been rejected or the request for the implicit
service 1 has not been discarded.

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext DRAGE, Keith (Keith)
Sent: Wednesday, February 22, 2012 3:18 AM
To: [email-masked]; [email-masked]
Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> C1: "to control the request and granting of the service, as in USS2 
> and UUS3" => just an editorial comment, "USS2" should be replaced by "UUS2".
> 
OK

> message" => in order to avoid any misunderstanding, it would be 
> clearer to indicate that this restriction concerns "isdn-uui" package, 
> so it would be in-line with section 6 where this precision is given 
> and with section 5 where another package could be used (enhanced 
> package) in parallel with "isdn-uui". Otherwise, without this 
> clarification, it could be understood as no other package is allowed.
> Proposal: "Only a single user information package set to "isdn-uui" 
> can be transported in each message".

> 
> **Section 5**
> C3: "the endpoint can carry the UUI data both as ISDN and as some 
> other package in parallel" => it would be suitable to explicitly 
> indicate that ISDN UUI and other types of UUI using other packages are 
> conveyed either in the same or in different messages.
> 
> 
> other types of UUI defined in other packages, in parallel in the same 
> or in different messages".

> 
> **Section 7**
> C4: "The UAC MUST only use this package of the UUI mechanism extension 
> in association with the initial INVITE method and the BYE method 
> relating to an INVITE dialog. Usage on transactions associated with 
> any other type of dialog, or on methods not associated with a dialog 
> is precluded." => The first sentence indicates that User-to-User 
> header can only be conveyed in initial INVITE request, its responses, 
> BYE request and its responses (which is consistent with the definition 
> of UUS1) whereas the scope of the second sentence is wider because it 
> means that other methods within the INVITE-initiated dialog (e.g. 
> UPDATE) can be used to convey UUI, although only initial INVITE and BYE methods are allowed.
> Proposal: "The UAC MUST only use this package [...]. Usage on 
> transactions associated with any other type of dialog, or on methods 
> not associated with a dialog, or on methods related to an INVITE 
> dialog but different from initial INVITE or BYE methods is precluded."
> 

> C5: "If the UAC wishes to user or permit the sending of UUI data at 
> any point in the dialog, the UAC MUST include in the INVITE request 
> for that dialog a User-to-User header field with an "package" header 
> field parameter set to "isdn-uui". This initial header field 
> constitutes the implicit request to use the UUI service, and is 
> therefore included even when there is no data except the protocol 
> discriminator octet to send at that point in time." => the use of 
> User-to-User header even with no uui data in INVITE request for 
> implicit request should be a possibility but not a requirement since 
> the uui option tag has been created for that purpose and allows as well to declare and negotiate the uui capacity.

> "package" header field parameter set to "isdn-uui" in any message of 
> an INVITE dialog if the original INVITE request did not include the 
> User-to- User header field with an "package" header field parameter 
> set to "isdn-
> uui".") => it should be allowed to include a User-to-User header even 
> if no User-to-User header was present in INVITE request since the 
> negotiation of the uui capacity can be done by uui option tag instead.

Propose rewording to:

> 
> C7: "Because for the ISDN UUI service, the service is service 1 
> implicit, the inclusion of the "uui" option tag in a Supported header 
> field conveys no additional information over and above the presence of 
> the User-to-User header field with the "package" header field 
> parameter to "isdn-uui" in the INVITE request. While there is no harm 
> in including the "uui" option tag, and strictly it should be included 
> if the extension is supported, it performs no function" => it should 
> be possible, in order to declare/negotiate the uui capability, to use 
> the uui option tag instead of the inclusion of User-to-User header 
> even with no uui data, at least by indicating both possibilities.
> Proposal: "While there is no harm in including the "uui" option tag, 
> and strictly it should be included if the extension is supported, it 
> performs no function when User-to-User header is included in INVITE 
> request for implicit request. Otherwise, the uui option tag is used to 
> indicate that a UA supports and understands the User-to-User header field."
> 

> C8: "When sending UUI for the ISDN package, the UAS MUST set the 
> User-to- User "package" header field parameter to "isdn-uui" and "When 
> receiving UUI, when a User-to-User header field is received in a 
> request that is not from the originating user with the "package" 
> header field parameter to "isdn-uui", the UAC MUST discard this header 
> fields." => this requires the presence of package parameter (with 
> value set to "isdn-uui"). In order to be consistent with 
> draft-ietf-cuss-sip-uui-04 ("If the "package" parameter is not 
> present, interworking with the ISDN UUI Service MUST be assumed"), it 
> would be necessary to add that when package parameter is not present, its default value "isdn-uui" must be assumed.
> Proposal (in reception): "When receiving UUI, when a User-to-User 
> header field is received in a request that is not from the originating 
> user with the "package" header field parameter to "isdn-uui", the UAC 
> MUST discard this header fields. When receiving UUI, if no package 
> header field parameter is present, the UAC must assume its default value "isdn-uui"".
> Proposal (in emission): "When sending UUI for the ISDN package, if the 
> UAS includes a User-to-User "package" header field parameter, it MUST 
> set it to "isdn-uui".
> 

> response that is not with the "package" header field parameter to 
> "isdn- uui" (discarded?).
> 
> **Section 8**

> registry of the SIP parameter registry: Value: isdn-uui" => it would 
> be suitable to rename the value of package parameter from "isdn-uui" 
> into "isdn-interwork". The goal would to allow compatibility with 
> already deployed implementations that are based on the draft-johnston 
> individual draft (draft referenced since a long time in 3GPP 
> documents). There would be no change regarding the meaning because the 
> definitions of "isdn- interwork" and "isdn-uui" values are exactly the 
> same, for ISDN interworking scenarios ("which is to interoperate with 
> ISDN User to User Signaling (UUS)").
> 

> De : [email-masked] [mailto:[email-masked]] De la part 
> de Vijay K. Gurbani Envoyé : jeudi 15 décembre 2011 17:15 À : 
> [email-masked] Objet : [cuss] Expert review of sip-uui-isdn draft 
> underway
> 
> will ask the editors to modify their respective drafts and proceed to 
> WGLC.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Feb 2012 18:45:43 +0100

I think the answer is in the text you extracted in the words: " the request for the implicit service 1 has not been discarded."

But to give you some quotes from the ISDN service description, ITU-T Recommendation Q.257.1.

"2.2.7  implicit request: The UUS supplementary service is considered as implicitly requested when no explicit request for the UUS supplementary service is made and UUI is sent by the user when originating a call."

Section: 3.2.1.1

"Service 1 can be activated by means of an implicit request or an explicit request. Service 1 is implicitly requested when UUI is included when originating a call. The served user shall be given an explicit response (acceptance or rejection) to an explicit request. An explicit request can include UUI."

And from ITU-T Recommendation Q.737.1:

"Service 1 may be requested implicitly by the presence of the user-to-user information parameter in the initial address message. An implicit request is "non-essential" by default.

...

On call set-up, the initial address message will contain the user-to-user information parameter. The user-to-user information will be received from call control and will be transported across the network and delivered unchanged to the terminating call control for the called user. The user-to-user indicators parameter will not be sent.

The reception of a user-to-user information parameter in a backward call control message from the terminating call control is an implicit indication of the acceptance of service 1."

I could make further quotes from ITU-T Recommendation Q.957.1 and ITU-T Recommendation Q.87.1 but they are all consistent in requiring the implicit request in the origination. The stage 2 seems even more emphatic with FEAs for checking the service is active on every data transfer.

There are only two types of requesting the service, implicit or explicit - there is no other type. Given that both implicit and explicit requests both refer to information included in the origination of the call (i.e. IAM or SETUP) that is the only options available.

I agree the implicit request can be empty of data, but that still means it contains the information element identifier, the length, and the protocol discriminator (which is a mandatory octet for the information element).

Therefore for the ISDN package, an implicit request must be in the first message, and that implicit request must be able to transport 1 octet of protocol discriminator.

Regards

Keith

> From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]]
> Sent: 23 February 2012 17:11
> To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
> Subject: RE: [cuss] Expert review of sip-uui-isdn draft underway
>
> Dear Keith, Celine,
>
> You wrote
>
> In my understanding (based on Q.737.1, quotation below) of ISUP UUS1
> implicit, UUS can be included in an ISUP response even if none was in the
> IAM.
>
> If I am correct, neither the original wording nor the proposed rewording
> of Keith allows for a proper interworking of the service. We should rather
> also allow "isdn-uui" within a User-to-User header in SIP responses
> irrespective of what was contained in the SIP request.
>
>
> ext DRAGE, Keith (Keith)
> My comments below indicating my proposed handing. I'll take this as I'ved
> indicated for the next draft unless I see alternative proposals or
> objections from members of the working group in the next 5 days or so.
>
> This sentence is talking about the ISDN service and how that works and its
> constraints, where there is no package concept. The sentence predates the
> use of the term "package" as part of the protocol and I guess it would be
> better to remove the term here to avoid confusion. I think just removing
> the word works best: "Only a single user information can be transported in
> each message."
>
> >
> > **Section 5**
> I propose adding "depending on the needs of the application" (after same
> or in different), otherwise I propose to follow the proposal here.
>
> >
> > **Section 7**
> I propose to follow this, except to make the proposal a separate sentence:
> "Usage on other methods within the INVITE dialog, and on re-INVITE
> transactions with the INVITE dialog, is also precluded."
>
>
> > the uui option tag has been created for that purpose and allows as well
> to declare and negotiate the uui capacity.
> I guess when I wrote the above requirement, I was working on what I
> understood the uui mechanism draft would say, because at that time it was
> not available. So we need to evaluate what we need to say.
>
> I agree that based on the current mechanism draft, on receipt without a
> "package" header field parameter "uui-isdn" has to be assumed.
>
> For sending, I believe an explicit indication would at least be good
> practice. I also believe it would be confusing if for example a media
> feature tag indicating "sip.uui-isdn" was included but a package header
> field parameter was not.
>
> " If the UAC wishes to use or permit the sending of UUI data at any point
> in the dialog, the UAC MUST include in the INVITE request for that dialog
> a User-to-User header field. The UAC SHOULD set the "package" header field
> parameter to "isdn-uui". Non-inclusion of the "package" header field
> parameter is permitted, but this is primarily to allow earlier
> implementations to support this package. This initial header field
> constitutes the implicit request to use the UUI service, and is therefore
> included even when there is no data except the protocol discriminator
> octet to send at that point in time."
>
> This is also going to result in a number of changes where reception of the
> "package" field is specified, to encompass the non-inclusion with the same
> meaning, I propose not to elaborate these here.
>
> I think "MAY" is the wrong solution to this comment. If there is an
> entirely different "package" header field parameter, continuing to assume
> this is "isdn-uui" would be inappropriate.
>
> Propose rewording to:
>
> " The UAC MUST NOT include the User-to-User header field with an "package"
> header field parameter set to "isdn-uui", or with no "package" header
> field parameter", in any message of an INVITE dialog if the original
> INVITE request did not include the User-to-User header field, either with
> an "package" header field parameter set to "isdn-uui", or with no
> "package" header field parameter included."
>
> >
> While this would work in the absence of ISDN interworking, if ISDN
> interworking was involved they there would be an extra complication to the
> interworking. In ISDN it is the presence of the user-to-user information
> parameter / information element in ISDN IAM / DSS1 SETUP message that
> indicates the request for the service. That is why it is called implicit.
> The presence of data implicitly requests the service.
>
> If we follow the proposal above, we effectively give the gateway two
> alternates to map an empty user-user received from ISDN, and have to deal
> with both those alternatives when received in SIP at the gateway.
>
> Moreover, in the ISDN there is no such thing as an empty user user, as it
> still has to contain the protocol discriminator. I quote for example
> Q.957.1: " Service 1 may be implicitly requested by including a User-to-
> user information element of variable length as specified in 4.5/Q.931 [1]
> in the SETUP message, transferred across the user network interface at the
> calling side as described in 5.1.1/Q.931 [1]. This information element is
> transported by the network and delivered unchanged in the User-to-user
> information element included in the SETUP message transferred across the
> user network interface at the called side as described in 5.2.1/Q.931 [1].
> For activation purposes, this information element must be at least three
> octets long, as defined in 4.5/Q.931 [1]."
>
> There are requirements elsewhere in the i-d to include the protocol
> discriminator as the minimum contents of the uuidata.
>
> > would be necessary to add that when package parameter is not present,
> " When receiving UUI, when a User-to-User header field is received in a
> request that is not from the originating user with the "package" header
> field parameter to "isdn-uui", or with no "package" header field
> parameter, the UAC MUST discard this header field."
>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 24 Feb 2012 10:01:16 +0100

Thanks Keith,

Seems I was mistaken. Your proposed rewording thus is fine for me.

Thomas

-----Original Message-----
From: ext DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, February 23, 2012 6:46 PM
To: Belling, Thomas (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [cuss] Expert review of sip-uui-isdn draft underway

Section: 3.2.1.1

...

Regards

Keith

> > > C6: "The UAC MUST NOT include the User-to-User header field with 
> > > an "package" header field parameter set to "isdn-uui" in any 
> > > message of an INVITE dialog if the original INVITE request did not 
> > > include the
> > > User-to- User header field with an "package" header field 
> > > parameter set to "isdn-
> > > uui".") => it should be allowed to include a User-to-User header 
> > > even if no User-to-User header was present in INVITE request since 
> > > the negotiation of the uui capacity can be done by uui option tag instead.
> entirely different "package" header
> >  set to "isdn-uui", or with no "package" header field parameter", in 
> > any
> message of an INVITE dialog
> >  if the original INVITE request did not include the User-to-User 
> > header
> field, either with an "package"
> field parameter included."
>
> implicit, UUS can be included in an ISUP response even if none was in 
> the IAM.
>
> If I am correct, neither the original wording nor the proposed 
> rewording of Keith allows for a proper interworking of the service. We 
> should rather also allow "isdn-uui" within a User-to-User header in 
> SIP responses irrespective of what was contained in the SIP request.
>
>
> 1.1.5.2.1.1.3 Transfer of user-to-user information User-to-user 
> information may be contained in any of the messages that may be 
> transferred in the call set-up and call release phases, independently 
> of whether the service is requested implicitly or explicitly, provided 
> that the explicit service 1 has not been rejected or the request for 
> the implicit service 1 has not been discarded.
>
>
> Thomas
>
>
> Of ext DRAGE, Keith (Keith)
> My comments below indicating my proposed handing. I'll take this as 
> I'ved indicated for the next draft unless I see alternative proposals 
> or objections from members of the working group in the next 5 days or so.
>
> > C2: "Only a single user information package can be transported in 
> > each message" => in order to avoid any misunderstanding, it would be 
> > clearer to indicate that this restriction concerns "isdn-uui" 
> > package, so it would be in-line with section 6 where this precision 
> > is given and with section 5 where another package could be used 
> > (enhanced
> This sentence is talking about the ISDN service and how that works and 
> its constraints, where there is no package concept. The sentence 
> predates the use of the term "package" as part of the protocol and I 
> guess it would be better to remove the term here to avoid confusion. I 
> think just removing the word works best: "Only a single user 
> information can be transported in each message."
>
> >
> > **Section 5**
> > indicate that ISDN UUI and other types of UUI using other packages 
> > are conveyed either in the same or in different messages.
> >
> >
> > Proposal: "the endpoint can carry the UUI data both as ISDN UUI and 
> > as other types of UUI defined in other packages, in parallel in the 
> > same or in different messages".
>
> I propose adding "depending on the needs of the application" (after 
> same or in different), otherwise I propose to follow the proposal here.
>
> >
> > **Section 7**
> > C4: "The UAC MUST only use this package of the UUI mechanism 
> > extension in association with the initial INVITE method and the BYE 
> > method relating to an INVITE dialog. Usage on transactions 
> > associated with any other type of dialog, or on methods not 
> > associated with a dialog is precluded." => The first sentence 
> > indicates that User-to-User header can only be conveyed in initial 
> > INVITE request, its responses, BYE request and its responses (which 
> > is consistent with the definition of UUS1) whereas the scope of the 
> > second sentence is wider because it means that other methods within the INVITE-initiated dialog (e.g.
> > UPDATE) can be used to convey UUI, although only initial INVITE and 
> > BYE
> methods are allowed.
> understood the uui mechanism draft would say, because at that time it 
> was not available. So we need to evaluate what we need to say.
>
> I agree that based on the current mechanism draft, on receipt without 
> a "package" header field parameter "uui-isdn" has to be assumed.
>
> feature tag indicating "sip.uui-isdn" was included but a package 
> header field parameter was not.
>
> Would changing the "MUST" to a "SHOULD be an appropriate solution", 
> along with some additional clarification.
>
> " If the UAC wishes to use or permit the sending of UUI data at any 
> point in the dialog, the UAC MUST include in the INVITE request for 
> that dialog a User-to-User header field. The UAC SHOULD set the 
> "package" header field parameter to "isdn-uui". Non-inclusion of the 
> "package" header field parameter is permitted, but this is primarily 
> to allow earlier implementations to support this package. This initial 
> header field constitutes the implicit request to use the UUI service, 
> and is therefore included even when there is no data except the 
> protocol discriminator octet to send at that point in time."
>
> This is also going to result in a number of changes where reception of 
> the "package" field is specified, to encompass the non-inclusion with 
> the same meaning, I propose not to elaborate these here.
>
> > uui".") => it should be allowed to include a User-to-User header 
> > even if no User-to-User header was present in INVITE request since 
> > the negotiation of the uui capacity can be done by uui option tag instead.
> entirely different "package" header field parameter, continuing to 
> assume this is "isdn-uui" would be inappropriate.
>
> Propose rewording to:
>
> INVITE request did not include the User-to-User header field, either 
> with an "package" header field parameter set to "isdn-uui", or with no 
> > implicit, the inclusion of the "uui" option tag in a Supported 
> > header field conveys no additional information over and above the 
> > presence of the User-to-User header field with the "package" header 
> > field parameter to "isdn-uui" in the INVITE request. While there is 
> > no harm in including the "uui" option tag, and strictly it should be 
> > included if the extension is supported, it performs no function" => 
> > it should be possible, in order to declare/negotiate the uui 
> > capability, to use the uui option tag instead of the inclusion of 
> > User-to-User header even with no uui data, at least by indicating both possibilities.
> > request for implicit request. Otherwise, the uui option tag is used 
> > to indicate that a UA supports and understands the User-to-User 
> > header
> field."
> >
> interworking was involved they there would be an extra complication to 
> the interworking. In ISDN it is the presence of the user-to-user 
> information parameter / information element in ISDN IAM / DSS1 SETUP 
> message that indicates the request for the service. That is why it is called implicit.
> alternates to map an empty user-user received from ISDN, and have to 
> deal with both those alternatives when received in SIP at the gateway.
>
> Moreover, in the ISDN there is no such thing as an empty user user, as 
> it still has to contain the protocol discriminator. I quote for 
> example
> Q.957.1: " Service 1 may be implicitly requested by including a 
> User-to- user information element of variable length as specified in 
> 4.5/Q.931 [1] in the SETUP message, transferred across the user 
> network interface at the calling side as described in 5.1.1/Q.931 [1]. 
> This information element is transported by the network and delivered 
> unchanged in the User-to-user information element included in the 
> SETUP message transferred across the user network interface at the called side as described in 5.2.1/Q.931 [1].
> For activation purposes, this information element must be at least 
> three octets long, as defined in 4.5/Q.931 [1]."
>
> > User-to- User "package" header field parameter to "isdn-uui" and 
> > "When receiving UUI, when a User-to-User header field is received in 
> > a request that is not from the originating user with the "package"
> > header field parameter to "isdn-uui", the UAC MUST discard this 
> > header fields." => this requires the presence of package parameter 
> > (with value set to "isdn-uui"). In order to be consistent with
> > present, interworking with the ISDN UUI Service MUST be assumed"), 
> > header field is received in a request that is not from the 
> > originating user with the "package" header field parameter to 
> > "isdn-uui", the UAC MUST discard this header fields. When receiving 
> > UUI, if no package header field parameter is present, the UAC must 
> > assume its default value
> "isdn-uui"".
> > Proposal (in emission): "When sending UUI for the ISDN package, if 
> > the UAS includes a User-to-User "package" header field parameter, it 
> > MUST set it to "isdn-uui".
> >
> " When receiving UUI, when a User-to-User header field is received in 
> a request that is not from the originating user with the "package" 
> header field parameter to "isdn-uui", or with no "package" header 
> field parameter, the UAC MUST discard this header field."
>
> > C9: As done in Section 8 for UAS, it would be relevant to indicate 
> > the behavior of the UAC when a User-to-User header field is received 
> > in a response that is not with the "package" header field parameter 
> > to
> > C10: "This document adds the following row to the "UUI packages" 
> > sub- registry of the SIP parameter registry: Value: isdn-uui" => it 
> > would be suitable to rename the value of package parameter from "isdn-uui"
> > already deployed implementations that are based on the 
> > draft-johnston individual draft (draft referenced since a long time 
> > in 3GPP documents). There would be no change regarding the meaning 
> > because the definitions of "isdn- interwork" and "isdn-uui" values 
> > are exactly the same, for ISDN interworking scenarios ("which is to 
> > interoperate with ISDN User to User Signaling (UUS)").
> >
>
> > Folks: Celine Serrutvalette has agreed to perform an expert review 
> > of the UUI ISDN draft (thanks, Celine).
> >