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
