Draft:  draft-johnston-sipping-cc-uui-06.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date: 12/09/2008
Review Deadline: 12/22/2008
Status: New


Summary: I believe this draft (especially the requirements section in this draft, which I think is what matters) is in good enough shape to send to SIP for protocol specification work.

Comments: I had a couple of questions (below), that do not affect readiness to send to SIP, and a couple of nits if the draft is revised for publication.

5.1.  Why INFO is Not Used

   Since the INFO method [RFC2976]., was developed for ISUP interworking

Spencer (nit): s/.,//

   of user-to-user information, it might seem to be the logical choice
   here.  For non-call control user-to-user information, INFO can be
   utilized for end to end transport.  However, for transport of call
   control user-to-user information, INFO can not be used.  As the call
   flows in the previous section show, the information is related to an
   attempt to establish a session and must be passed with the session
   setup request (INVITE), responses to that INVITE, or session
   termination requests.  As a result, it is not possible to use INFO in
   these cases.

5.3.  URI Parameter

   Another proposed approach is to encode the UUI as a URI parameter
   into the Contact or Refer-To URI.

  <allOneLine>
  Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6
  F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
  </allOneLine>

   An INVITE sent to this Contact URI would contain UUI in the Request-
   URI of the INVITE.  The URI parameter has a drawback in that a URI
   parameter will not survive retargeting by a proxy as shown in Figure
   2.  That is, if the URI is included with an Address of Record instead
   of a Contact URI, the URI parameter will not be copied over to the
   Contact URI, resulting in the loss of the information.  As a result,
   this approach does not meet REQ-4.

Spencer: does the Refer-To URI have the same problem here?

5.4.  Header Field Approach

      Call-Info usually contains a URI pointer the information instead
      of the actual information itself which does not REQ-5.  It could

Spencer (nit): s/not/not meet/

      be possible to use a data URI to carry the UUI directly in this
      header field.

7.  Appendix - Syntax for UUI Header Field

   Current usage is to interoperate with ISDN User to User Signaling
   (UUS), a supplementary service in which manufacturer specific
   information is transported via the codeset 0 User-user Information
   IE.  Three services are defined: service 1, service 2, and service 3.
   This draft only addresses the SIP equivalent of service 1 although it
   could easily be expanded later to address services 2 and 3.  UUS
   Service 1 involves user to user signaling exchanged during call setup

Spencer (nit): s/user to user/user-to-user/

   and clearing within the following Q.931 call control messages: SETUP,
   ALERT, CONNECT, DISCONNECT, RELEASE, and RELEASE COMPLETE.  UUS
   Service 2 involves user to user signaling exchanged during call
   establishment (between ALERT and CONNECT) via the USER INFORMATION
   message.  This service usually has a maximum of 2 USER INFORMATION
   messages in each direction.  UUS Service 3 involves user to user
   signaling exchanged on an active call via the USER INFORMATION
   message.

8.  Security Considerations

   Received User-to-User information should only be trusted if it is
   authenticated or received within a trust domain.  For example,

Spencer: is "authenticated within a trust domain" sufficient? (I'm not quite sure how you know that you've received UUI within a trust domain, so I may not have understood what you're saying here.

   Spec-T, defined in [RFC3324] could be used to define a trust domain.
   When utilized by a gateway to map information to or from ISDN Q.931,
   appropriate policy should be applied based on the PSTN trust domain.