ietf
[Top] [All Lists]

Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)

2010-07-01 13:51:52


Mohamed Elithy wrote:
Hi!
We are currently adding all 3 parameters (encoding, content, and purpose) in case 
of an ISDN --> SIP initiated call with their specified default values defined 
in section 5 of the draft.

As far as the formatting, as the draft specifies the first byte of the header 
value is the protocol discriminator. we found that the best way to satisfy 
multiple customers dealing with different types of encoding is to pass the 
protocol discriminator along with the raw byte stream from the UUI IE on the 
ISDN side to the UUI header on the SIP side. This way the SIP AS or any other 
SIP entity receiving that header can decide how to decode the UUI info based on 
the value of the protocol discriminator.

I got all that. My question was about what specific value(s?) of the protocol discriminator are you using, and how do they correspond to the rest of the value.

The same question would apply if sip were not involved at all - if the call were an ISDN call.

Is there a broad based convention that most call center sw will use a particular encoding?

Or is it well known that certain commercial products use certain encodings?

Or is this just a private side arrangement configured between the caller and the callee in a specific deployment?

        Thanks,
        Paul

Hope this helps.

Regards,
-Mohamed

Mohamed Elithy | Engineering Manager/Architect | Dialogic Inc. | 
mohamed(_dot_)elithy(_at_)dialogic(_dot_)com | 508-862-3722 W | 508-364-5526 M

This e-mail is intended only for the named recipient(s) and may contain 
information that is privileged, confidential and/or exempt from disclosure 
under applicable law. No waiver of privilege, confidence or otherwise is 
intended by virtue of communication via the internet. Any unauthorized use, 
dissemination or copying is strictly prohibited. If you have received this 
e-mail in error, or are not named as a recipient, please immediately notify the 
sender and destroy all copies of this e-mail.


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat(_at_)cisco(_dot_)com]
Sent: Wednesday, June 30, 2010 2:20 PM
To: James Rafferty
Cc: Gonzalo Camarillo; dispatch(_at_)ietf(_dot_)org; DRAGE, Keith (Keith); 
ietf(_at_)ietf(_dot_)org; Mohamed Elithy
Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)

James,

Can you shed some light on *how* this is used, given the lack of any
standards on the content/formatting of this information?

Do you use content=isdn-uui and some particular Q.931 protocol
discriminator for which there are formatting standards?

Or is this only used between a caller and a callee that have somehow
obtained contextual information that they both support this feature
*and* a particular encoding?

        Thanks,
        Paul

James Rafferty wrote:
Hi,

My company has had the experience of deploying the pre-standard version of this 
PSTN to SIP UUI mechanism during the past 2 years.

As noted in the draft charter, UUI information is widely used on the PSTN for 
applications such as offering input data into call centers and then preserving 
that data as calls get transferred.

Since many contact centers are now built using SIP, but still have PSTN subscribers (via 
SS7 ISUP or ISDN PRI), there is a need to be able to interwork the user to user 
information from the PSTN side into SIP.  In our experience, the "Johnston uui 
draft" has accomplished this and we have several customers that find this 
interworking to be valuable.  We also noted improvements from early drafts into the later 
ones in areas such as making better use of the ITU-T protocol discriminator, thus 
enabling better interoperability from the PSTN side into SIP.

The major deficiency of the current draft is its non-standard status. 
Functionally, we and our customers find this mechanism to be very useful and 
I'd very much like the IETF to charter the a UUI work group to standardize such 
a mechanism.

James
-----Original Message-----
From: dispatch-bounces(_at_)ietf(_dot_)org 
[mailto:dispatch-bounces(_at_)ietf(_dot_)org] On Behalf Of Gonzalo Camarillo
Sent: Wednesday, June 30, 2010 2:51 AM
To: Paul Kyzivat
Cc: dispatch(_at_)ietf(_dot_)org; DRAGE, Keith (Keith); ietf(_at_)ietf(_dot_)org
Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)

Hi,

please keep both the IETF and the DISPATCH mailing lists in the
recipients list in this discussion.

Cheers,

Gonzalo


On 29/06/2010 8:23 PM, Paul Kyzivat wrote:
DRAGE, Keith (Keith) wrote:
The UUI information is NOT ISUP. It is a transparent envelope to the entire 
ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP 
protocol. When carried by ISUP the envelope is bundled up in another envelope 
with other information that ISUP carries transparently.

So I believe, and have said repeatedly in the past, that references to SIP-T 
are irrelevant in this case.

The problem we do have though is that are legacy usages of this information. In 
particular applications in PBXs carry it between themselves in ISDN call 
establishment. The information itself is not standardised. If you want to 
migrate a PBX from DSS1 to SIP, then you have to take this information into 
account. The desire is not for a WG group to standardise this existing usage 
(which in my view would be a complete non-starter), but to allow the transfer 
of the existing information when migrated to a SIP environment. The information 
transferred does not form part of SIP, and should not be standardised as part 
of SIP.
How many different mechanisms do we have to construct for the purpose of
tunneling stuff over SIP?

Its especially bad if the stuff is neither standardized nor negotiated.
It then just provides more opportunity for non-interoperability.

It had been my impression that this content was standardized by ITU.
If nobody can bother to standardize it, then it hardly seems worth
working on.

        Thanks,
        Paul

regards

Keith



-----Original Message-----
From: dispatch-bounces(_at_)ietf(_dot_)org
[mailto:dispatch-bounces(_at_)ietf(_dot_)org] On Behalf Of
bruno(_dot_)chatras(_at_)orange-ftgroup(_dot_)com
Sent: Tuesday, June 29, 2010 1:00 PM
To: Gonzalo(_dot_)Camarillo(_at_)ericsson(_dot_)com; 
dispatch(_at_)ietf(_dot_)org
Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI
for SIP (cuss)

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

_______________________________________________
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