Re: WG Review: Call Control UUI for SIP (cuss)

[Laura Liess <[e-mail]>]

Cullen,

Bruno is right.

SIP-T is used today for tunneling ISUP in SIP. In many cases  people
don't implement SIP-T at all, because they intend to migrate the
network to full SIP,  but still need to interwork with PSTN for a
while. Should we require ISUP-capabilities for SIP application
servers? We just need a way to transport a piece of data between SIP
application servers, SIP end devices and PSTN. The solution can not be
ISUP.

>>  However, I
>> think this charter should be rejected by the IESG and sent
>> back to the drawing board.

The need for UUI was recognized back in 2006,  when we had the first
draft with this proposal see
http://tools.ietf.org/id/draft-johnston-sipping-cc-uui-00.txt . We
discussed the issue a number of times and people stated their need for
this. We have now 2010.

Laura


2010/6/29  <[e-mail]>:
> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does state that SIP-T does not come into play when there is no PSTN involved.
>
> At the end of clause 2 we can read the following: "4.  IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking."
>
> Besides, SIP-T would require encapsulating a full ISUP message (e.g. IAM) while we are interested in just one parameter of the message in the context of CUSS. This would I believe be a more severe drawback if SIP-T were used for this purpose.
>
> Bruno
>
>
>> -----Message d'origine-----
>> De : [e-mail]
>> [mailto:[e-mail]] De la part de Gonzalo Camarillo
>> Envoyé : mardi 29 juin 2010 13:03
>> À : DISPATCH
>> Objet : [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)
>>
>> Hi,
>>
>> FYI: note the discussion below on the IETF general list.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> -------- Original Message --------
>> Subject: Re: WG Review: Call Control UUI for SIP (cuss)
>> Date: Mon, 28 Jun 2010 20:24:23 +0200
>> From: Cullen Jennings <[e-mail]>
>> To: [e-mail] <[e-mail]>
>> CC: IETF Discussion Mailing List <[e-mail]>
>>
>>
>> As far as I can tell, the WG says they wants to transfer some
>> information to achieve cross vendor interoperability.
>> However, what I believe the charter is actually going to do
>> is exactly the opposite of that. When you get your head
>> around what this charter is proposing, it is going to form a
>> more or less opaque container for transporting proprietary
>> information in a SIP header. It's hard to imagine how this
>> will help interoperability.
>>
>> If we wanted to have interoperability, the charter would say
>> what information needs to be transferred and have the WG
>> define a way to get it between systems in an operable way.
>> What the charter for this WG actually says they are going to
>> do is make a special container for transfer proprietary
>> information.  There's not even willing to say what that
>> proprietary information is used for other than things ISDN
>> UUI which is a  non interoperable and fairly proprietary
>> field in ISDN.
>> Furthermore they have asserted that  existing containers such
>> as SIP-T or SIP bodies can't be used for reasons that are
>> hard to describe. (I reject the idea that because the call
>> might not involved the PSTN, it can't use SIP-T).
>>
>> I think the folks that want to do this should get a much
>> clear explanation of how this results in interoperability and
>> why exist approach such as SIP-T will not work before this is
>> chartered.
>>
>> I do think there is a need to standardize some important call
>> control information used in call centers and related places.
>> However, the "we need a standard container to exchange secret
>> information WG" is a bad idea and violates the sprit of the
>> SIP change process not to mention the mission of the IETF.
>>
>> In summary, I'm in favor of figuring out what the problems
>> are people hope to solve with this WG and figuring out a way
>> to write interoperable standards to achieve that. However, I
>> think this charter should be rejected by the IESG and sent
>> back to the drawing board. The RAI area has things of higher
>> priority items to work on than a SIP header for transfer
>> proprietary data.
>>
>>
>>
>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote:
>>
>> > A new IETF working group has been proposed in the Real-time
>> > Applications and Infrastructure Area.  The IESG has not
>> made any determination as yet.
>> > The following draft charter was submitted, and is provided for
>> > informational purposes only. Please send your comments to the IESG
>> > mailing list ([e-mail]) by Tuesday, June 29, 2010.
>> >
>> > Call Control UUI for SIP  (cuss)
>> > --------------------------------------------------
>> > Current Status: Proposed Working Group
>> >
>> > Last modified: 2010-06-21
>> >
>> > Chair(s):
>> >  TBD
>> >
>> > Real-time Applications and Infrastructure Area Director(s):
>> >  Gonzalo Camarillo <[e-mail]>  Robert Sparks
>> > <[e-mail]>
>> >
>> > Real-time Applications and Infrastructure Area Advisor:
>> >  Gonzalo Camarillo <[e-mail]>
>> >
>> > Mailing Lists: TBD
>> >
>> > Description of Working Group:
>> >
>> > The Call Control UUI for SIP (CUSS) working group is chartered to
>> > define a Session Initiation Protocol (SIP) mechanism for
>> transporting
>> > call-control related user-to-user information (UUI) between User
>> > Agents.
>> >
>> > The mechanism developed in this working group is applicable in the
>> > following situations:
>> >
>> > 1. The information is generated and consumed by an application using
>> >   SIP during session setup but the application is not necessarily
>> >   even SIP aware.
>> > 2. The behavior of SIP entities that support it is not significantly
>> >   changed (as discussed in Section 4 of RFC 5727).
>> > 3. Generally only the User Agent Client (UAC) and User Agent Server
>> >   (UAS) are interested in the information.
>> > 4. The information is expected to survive retargeting, redirection,
>> >   and transfers.
>> > 5. SIP elements may need to apply policy about passing and screening
>> >   the information.
>> > 6. Multi-vendor interoperability is important.
>> >
>> > This mechanism is not applicable in the following situations:
>> >
>> > 1. The behavior of SIP entities that support it is significantly
>> >   changed (as discussed in Section 4 of RFC 5727).
>> > 2. The information is generated and consumed at the SIP layer by SIP
>> >   elements.
>> > 3. SIP elements besides the UAC and UAS might be interested in
>> >   consuming (beyond applying policy) the information.
>> > 4. There are specific privacy issues involved with the information
>> >   being transported (e.g., geolocation or emergency-related
>> >   information).
>> >
>> > User data of the mechanism will be clearly marked with the
>> > application, encoding, semantics, and content type,
>> allowing policy to
>> > be applied by UAs.  The working group will define the
>> information that
>> > each application must specify to utilize the mechanism.
>> This type of
>> > application-specific information will be specified in
>> standards-track
>> > documents.
>> >
>> > One important application of this mechanism is interworking
>> with the
>> > ISDN User to User Information Service.  This application defined by
>> > ITU-T Q.931 is extensively deployed in the PSTN today
>> supporting such
>> > applications as contact centers, call centers, and automatic call
>> > distributors (ACDs).  A major barrier to the movement of these
>> > applications to SIP is the lack of a standard mechanism to
>> transport
>> > this information in SIP.  For interworking with ISDN, minimal
>> > information about the content of the UUI is available to
>> the PSTN-SIP
>> > gateways.  In this case only, the content will just
>> indicate ISDN UUI
>> > Service 1 interworking rather than the actual content.
>> >
>> > Call control UUI is user information conveyed between user agents
>> > during call control operations.  As a result, the
>> information must be
>> > conveyed with the INVITE transaction, and must survive proxy
>> > retargeting, redirection, and transfers.  The mechanism
>> must utilize a
>> > minimum of SIP extensions since it will need to be
>> supported by many
>> > simple SIP user agents such as PSTN gateways.  The mechanism must
>> > interwork with the existing ISDN service but should also be
>> extensible
>> > for use by other applications and non-ISDN protocols.
>> >
>> > Even though interworking with the PSTN is an important requirement,
>> > call control UUI can be exchanged between native SIP
>> clients that do
>> > not have any ISUP support. Therefore, existing SIP-T
>> > encapsulation-based approaches defined in RFC3372 do not meet the
>> > requirements to transport this type of information.
>> >
>> > Mechanisms based on the SIP INFO method, RFC2976, will not be
>> > considered by the working group since the UUI contents carry
>> > information that must be conveyed during session setup at the user
>> > agent - the information must be conveyed with the INVITE
>> transaction.
>> > The information 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.
>> >
>> > The group will produce:
>> >
>> > - A problem statement and requirements document for
>> implementing a SIP
>> > call control UUI mechanism
>> >
>> > - A specification of the SIP extension to best meet those
>> requirements.
>> >
>> > Goals and Milestones
>> > ====================
>> >
>> > Sep 10 - Problem statement and requirements document to IESG
>> > (Informational)
>> > Mar 11 - SIP call control UUI specification to IESG (PS)
>> > _______________________________________________
>> > IETF-Announce mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>>
>> Cullen Jennings
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>