-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Cullen Jennings
Sent: Saturday, November 15, 2008 10:03 PM
To: Joanne McMillen; Alan Johnston
Cc: sipping
Subject: draft-johnston-sipping-cc-uui-05
So I'm just trying to help this move forward in a expedient
way that solves the need of the people that want it. I will
no doubt regret sending this message because this is not a
draft I plan to spend a lot of time on - however, I would
rather see the draft find a way to quickly address and move
past objects that I view as likely to come up about it sooner
or later. In the past we have had some ideas that went round
and round the WG for a long time with little progress. Some
of these had a characteristic argument that went a bit like:
It's meant to be from UA that understand it to UA that
understand it, which would be tunneling, but it's not
tunneling because proxies might read it too, and if they
understand it, they route the call differently than if they
did not understand it, but proxies are not required to
understand it, unless of course you want your call to be
routed correctly so you have to support it. And the content
of the data being transmitted is not specified and we can't
say what any device would do with it or how that would be implemented.
I hope this draft is not making an argument remotely close to
that because if it is, I predict it will be in the WG for a long time.
Right now, when I remove the text about the motivation for
the draft, the normative behavior I get left with is a new
header that carries unspecified but important binary data in
requests and responses (with no limit on data size) and and
an option tag which may or may no be used. I can not imagine
any way where two vendors could take that level of
specification and build interoperable equipment.
A separate topic that is tangentially related to this draft
is we have also seen a steady stream of just one more ISDN
parameter in yet another unstructured way. All the parameters
in ISDN are useful for someone for something - if we are
going to be adding them to sip headers or tel URI parameters,
I'd rather have some way of deciding which ones we add and
which one we don't instead of doing each one one at a time.
I'm not arguing you should use NSS, but I do wish we had some
sort of "test" that we could apply to decide what sort of
ISDN parameters we want to include and which ones are better
deal with some other way.
Cullen in my individual contributor role.
On Nov 12, 2008, at 6:35 PM, Joanne McMillen wrote:
in line...
----- Original Message -----
From: Cullen Jennings
To: Alan Johnston
Cc: sipping ; Joanne McMillen
Sent: Wednesday, November 12, 2008 4:06 PM
Subject: Re: [Fwd: New Version Notification for draft-
johnston-sipping-cc-uui-05]
I just started actually thinking about this draft and it made me
wonder about the requirements.
Is the need here to tunnel the ISDN UUIE from UAC to UAS or is it a
requirement that all the SIP routing elements need to
understand the
UUIE? Without understand what part of the network is required to
support this, makes it sort of hard to decide what is the
best way to
do this.
[Joanne] Why is this an either or? This is not about "tunneling".
Nor is it about
all routing elements needing to understand it. Routing
elements that
do not understand it at all and work accordingly for any
SIP headers
they do not understand/support simply pass the headers on.
It's about
any element that chooses to understand the content and act upon it.
And that is up to an agreement between elements because the actual
content of it needs to be agreed upon between them as it
will signal
only what they agreed to - it does not have any standard
content that
just any entity could translate. Even in ISDN it was something that
went blindly through PSTNs, but that could be acted upon by
any "user"
entity. Gee, does that sound like a B2BUA in SIP or what? Does IETF
still take the stance in SIP that a B2BUA is "your own
devil to deal
with"? ;-) If we can just get the header defined then there is the
same mechanism in SIP that intermediate B2BUAs could indeed
choose to
play with in SIP - or not - their choice - just like "user
end PBXs"
in ISDN...
There are many interested parties in what we can do with
this in SIP
while full well understanding that ultimately if we have to get the
information through a SP with an
SS7 backbone then this
is how it needs to be done.
I was also wondering if Q.1980.1 NSS pretty much solved
this problem
or if something more was needed.
[Joanne] Oh come on Cullen - we both know the answer to
that. Yes - if
you want a tunneling solution.
Most folks I have talked to about NSS have two responses - an
irritated sigh with eyeball roll is the nice one.
Doing this via NSS is like using a tank to kill a snail. This is
exactly why we have this draft...
Cullen <with my individual contributor hat on>
On Oct 31, 2008, at 13:17 , Alan Johnston wrote:
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
_______________________________________________
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
