This reflects and resolves my comments made in Dublin.
In regard to the open issues:
OPEN ISSUE: Should we allow multiple User-to-User header fields in
SIP even though ISDN does not support this? If so, we would need
to provide guidance for a SIP to ISDN gateway for mapping, such as
map the first header field and drop the rest.
My answer would be no. This is primarily intended for interworking with
the ISDN, and therefore there would be a high expectation that any
subsequent UUI data would be dropped.
OPEN ISSUE: Is there an advantage in extracting the protocol
discriminator and encoding in a header parameter? What would a
SIP UA do with this information?
Again no. It is important that the protocol discriminator is known to be
included in the data, but it is outside the SIP protocol, and therefore
we should not provide a SIP encoding for it.
I have one minor comment, I am not entirely convinced by requirement 7,
and therefore the need for an option tag. If I recall correctly the ISDN
implicit service is not guaranteed. If you want that guarantee, then you
need the explicit service.
NIT 1: The convention in DSS1 is to write an information element as Xyz
abc information element, i.e. only the first letter of the first word
capitalised.
NIT 2: Text
This section discusses four uses cases for the transport of call
control related user to user information. What is not discussed here
is the transport of non-call control UUI which can be done using the
SIP INFO method. These use cases help explain the requirements from
the previous section.
I would remove the reference to non-call control UUI, as firstly INFO as
in ISUP usage can contain call control information, and other methods
also exist apart from INFO for other information.
regards
Keith
> -----Original Message-----
> From: sipping-bounces@xxxxxxxx
> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Alan Johnston
> Sent: Friday, October 31, 2008 8:18 PM
> To: sipping
> Cc: Joanne McMillen
> Subject: [Fwd: New Version Notification
> fordraft-johnston-sipping-cc-uui-05]
>
> We have revised the UUI draft based on comments in Dublin.
>
> The major changes are:
>
> 1. Added 7 requirements for the mechanism.
> 2. Removed some controversial proxy use cases.
>
> Comments are most welcome.
>
> Thanks,
> Alan
>
> -------- Original Message --------
> Subject: New Version Notification for
> draft-johnston-sipping-cc-uui-05
> Date: Fri, 31 Oct 2008 13:13:58 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmission@xxxxxxxx>
> To: alan@xxxxxxxxxxxxxx
> CC: joanne@xxxxxxxxx
>
>
>
> A new version of I-D, draft-johnston-sipping-cc-uui-05.txt
> has been successfuly submitted by Alan Johnston and posted to
> the IETF repository.
>
> Filename: draft-johnston-sipping-cc-uui
> Revision: 05
> Title: Transporting User to User Call Control
> Information in SIP for ISDN Interworking
> Creation_date: 2008-10-31
> WG ID: Independent Submission
> Number_of_pages: 16
>
> Abstract:
> Several approaches to transporting the ITU-T Q.931 User to
> User Information Element (UU IE) data in SIP have been
> proposed. 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 the
> information to/from ISDN for end-to-end transparency. This
> extension will also be used for native SIP endpoints
> implementing similar services and interworking with ISDN
> services. This document discusses requirements and
> approaches and recommends a new header field User-to-User be
> standardized. Example use cases include an exchange between
> two User Agents, retargeting by a proxy, and redirection. An
> example application is in an Automatic Call Distributor (ACD)
> in a contact center.
>
>
>
>
> The IETF Secretariat.
>
>
>
>
>
> _______________________________________________
> 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
