ietf
[Top] [All Lists]

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

2010-06-29 11:02:35
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  <bruno(_dot_)chatras(_at_)orange-ftgroup(_dot_)com>:
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 : dispatch-bounces(_at_)ietf(_dot_)org
[mailto:dispatch-bounces(_at_)ietf(_dot_)org] 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 <fluffy(_at_)cisco(_dot_)com>
To: iesg(_at_)ietf(_dot_)org <iesg(_at_)ietf(_dot_)org>
CC: IETF Discussion Mailing List <ietf(_at_)ietf(_dot_)org>


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 (iesg(_at_)ietf(_dot_)org) 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 <Gonzalo(_dot_)Camarillo(_at_)ericsson(_dot_)com> 
 Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com>

Real-time Applications and Infrastructure Area Advisor:
 Gonzalo Camarillo <Gonzalo(_dot_)Camarillo(_at_)ericsson(_dot_)com>

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
IETF-Announce(_at_)ietf(_dot_)org
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
dispatch(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>