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
