Keith,
The way these services work the UUI is indeed from B - not
A.
There is no need for C to even know that - all C knows is
there is UUI associated with the call.
It works like this for the transfer case:
1) Call comes into a call center from some user in the
public network (wanting to place an order)
2) At the call center, the caller's ID (Calling Party
Number) is used to access their account information
(Or perhaps the caller identity is
determined by an IVR that answered the call)
3) The call center determines that the best place to handle
the call (least wait time in queue) is actually a remote branch of the call
center
4) The call center initiates a new call through the public
network to the remote branch and the first branch (B) sends the
UUI
it obtained for the caller with that
new call
5) The call center requests the public network (using
Facility IEs) to direct connect the caller to the remote branch
6) The public network drops the two original calls (the
inbound and outbound) at the original call center
branch and connects the public
network caller directly to the remote branch as requested
Technically speaking, the UUI was from B to C although it
"relates" to A certainly.
These network services are used to rid call centers of calls
simply looped through a PBX when the two parties left on
the call are actually elsewhere and can be directly
connected - facility savings. Call centers love those kinds of network
features.
There are indeed public networks that support this. Yes,
there is indeed an interworking implication there - that is
very
straight forward to interwork with and not lose the
UUI. That's why having the UUI encoding like ISDN is a very
attractive industry solution - so it can be easily
interworked. There are gateways today that can interwork SIP
signaling
(REFER) to that kind of ISDN service - and now they can do
so and not lose the UUI. As for UUI content, well that is and always has been
entirely up to
local policy for the end users that are
utilizing it. Sometimes UUI is overwritten and sometimes it may
be
appended to. It's up to the two end users to agree on what
the UUI is and how
it is interpreted. Intermediate entity's either simply
"provide" the UUS service (as being indicated below - if they get
it
they simply pass it). Or... they can actually "use" the
service and insert/modify UUI. The public network does not
care - they simply "provide" the service and transmit it
through their network. It's up to the two end users
to agree on what that information is and how it's used. It's
always been that way.
We can't have words in here for UUI treatment in SIP that
does not allow for the same features that are available in ISDN
today.
So, I'm not quite sure why we are getting ourselves wrapped
around the axle regarding the redirect concept in SIP
(whether it be diversion using a 302 or a transfer). The
call center will be inserting UUI in either case so when one looks
at
it from the purist point of view I guess that does translate
to the UUI being from B to C rather than A to C. Although
UUI is also used in cases where it indeed would be from A to
C - we just can't rule out the redirect cases
because they are available in ISDN.
Jo
----- Original Message -----
Sent: Thursday, December 11, 2008 4:56
AM
Subject: RE: Initial WG
review: draft-johnston-sipping-cc-uui-06
However there are implications in the draft that go
beyond ISDN (as defined by ITU-T service descriptions and as represented in
the ISO private network equivalents) in this case. Note that while the stage
1 and stage 2 for the ISDN public networks cover diversion using both
forward switching and redirection, forward switching is the only bit
implemented in the public network due to charging issues. Redirection does
occur across the PBX-public network interface.
In ISDN if A calls B and B redirects to C, then any UUI
that A sends to B is redirected to C.
The draft implies that B is allowed to include its own
personal UUI and that this will be given to C, and I believe this is not
covered in the ISDN case.
My understanding is that while in the ISDN the
rerouteing request contains UUI, it is the original UUI from the A user that
is sent back to the point of redirection as this will not have been
preserved at these intermediate points.
Thus in section 4.3 of the draft, F2 should only
contain UUI if F1 contains the UUI in the first place, and all the redirect
server is doing is reflecting it back.
Note that I do not necessarily have concerns about
extending the ISDN service, but we do need to be clear of the use cases
where this occurs, and also make sure that there are no interworking
implications with the ISDN service. Thus an ISDN user C receiving UUI will
have expected this to have come from the A user. If B happens to be a SIP
user and inserting its own UUI, what occurred to any original UUI from the A
user, and how do we tell the C user that this UUI is now really from user
B.
regards
Keith
Joanne,
It seems I was mistaken about ISDN not supporting a
redirection capability for UUI. If that is the case, then my concern goes
away.
John
in line...
----- Original Message -----
Sent: Tuesday, December 02, 2008
11:51 PM
Subject: RE: Initial WG
review: draft-johnston-sipping-cc-uui-06
Alan and Joanne,
Looking at the redirection example, I
could imagine a similar case but
using proxying (retargeting or
rerouting) rather than redirection. In
this case the proxy would
insert the UUI in the forwarded request. Is
see no requirement for
this in section 3.
However, PSTN/ISDN does not support
capabilities equivalent to insertion
by a proxying or redirecting
entity.
[Joanne] PSTN/ISDN most certainly allows for transition of
UUI with redirect - and that is
a very important point... see more information below...
Yet in section 1 it states:
"This document looks only at
the
requirements and mechanisms for replicating the
existing, widely used
and deployed ISDN UUI
service."
Therefore we should either:
- remove the redirection case,
on the grounds that it doesn't replicate
existing ISDN UUI
operation; or
[Joanne] Redirection most certainly does replicate current ISDN
behavior - there are
ISDN standards supported by PSTNs where they actually do a
redirect as requested
by a PBX - ANSI Explicit Network Call Transer and ETSI Network
Call Deflection
are two popular specs supported and used with PSTNs -
both of them allow for
transmitting the UU IE as part of that PSTN redirect service
for private networks. Hence, the SP redirect case
here is certainly 100% valid in SIP. If we do something to
disallow it in SIP (or just ignore it) then we are going
to cause interop problems and certainly not have parity with ISDN
for full UUI transmission support
for redirects... and the industry needs that...
- clarify the statement in section 1 so as not to preclude
the
redirection case.
Furthermore, if we adopt the second of
these approaches we might wish to
consider adding a requirement for
insertion by a proxy. Fortunately the
chosen mechanism would seem
to permit this.
I have no strong feelings which approach we
should take. I just wish to
see
consistency.
John
> -----Original
Message-----
> From:
sipping-bounces@xxxxxxxx
> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Mary
Barnes
> Sent: 02 December 2008 00:49
> To:
sipping@xxxxxxxx> Cc:
Gonzalo Camarillo
> Subject: Initial WG review:
draft-johnston-sipping-cc-uui-06
>
> Hi folks,
>
> This email is intended to announce an initial WG review for
> the following document:
>
http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-
>
uui-06.txt
> <
http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc>
-uui-06.txt>
>
> There was strong consensus to
complete the problem statement
> and requirements in the
SIPPING WG session (i.e., WGLC) and
> then propose that the
solution be worked in SIP WG - with the
> obvious understanding
that SIP WG must go through the process
> of taking on a new
work item. And, of course, the chairs
> will work
with the AD to get the appropriate milestones added
> to
SIPPING WG charter.
>
> In order to progress this
document in the SIPPING WG, we
> would like at least 3 (ideally
4) dedicated reviewers. So,
> please let us know ASAP if you
would be willing to serve as a
> reviewer. If we don't
get volunteers, I will pick on people,
> but it would be great
to get some new reviewers into the pool.
>
> In
terms of feedback, as well as technical comments, we would
>
like to hear views on whether this doc is ready for WGLC
>
(note that this document has been in the WG as an individual
>
draft for over two years).
>
> Please send any and all
comments on or before Dec. 22nd, 2008
> (3 weeks time).
>
> Regards,
> Mary.
> SIPPING WG co-chair
>
>
