----- Original Message -----
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
