Re: Initial WG review: draft-johnston-sipping-cc-uui-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Spencer,

Thanks very much for your review. We will fix the nits you found. A few comments below.

Thanks,
Alan


Spencer Dawkins wrote:
Initial WG review: draft-johnston-sipping-cc-uui-06

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@xxxxxxxxxxxxxxxxxxx;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?

Let me see if I understand your question. Are you asking if we had a Refer-To header field in a REFER like:

<allOneLine>
Refer-To: <sip:+12125551212@xxxxxxxxxxxxxxxxxxx;uui=ZeGl9i2icVqaNVailT6
F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>

Would the UUI get lost after proxy retargeting of the resulting INVITE?

The answer is yes - the problem applies here, too.



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.

This is confusing. I agree that "authenticated within a trust domain" doesn't make sense. We will clarify the sentence to:

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

As for how you tell if you have received it within a trust domain, I believe a typical Spec-T will say that message content is trusted if it is received in an authenticated message from a member of your trust domain.


  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.

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux