Subject: Re: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

From: "Joanne McMillen" <[email-masked]>
Date: Thu, 11 Dec 2008 07:34:18 -0800

BTW - probably should clarify the network deflection case as well (when the original call is unanswered so it doesn't
result in a transfer join/drop scenario).

In that case, the network service is still invoked by sending the FACILITY message to the public network, but
it instructs the network to actually redirect the call itself (at that point the original call center branch
has only the one call, not the second one as well resulting from the transfer). In that message there just
happens to be a place where UUI can be inserted to send with that call when the network deflects it to the
remote branch. 
Then when the network is successful
in establishing the caller with the remote branch it drops the call to the original branch.
It results in the same thing - caller connected directly to the remote branch
and the original branch dropped. Again, one could say that 
technically speaking that UUI was from B to C - not A to C because it was still created 
at point B (the original call center).

In the SIP world, the transfer service would utilize REFER/Replaces and the deflection service would
utilize 302. Hence, the SIP UUI header is needed in both SIP scenarios (answered or unanswered original call) for SIP to 
be able to provide the same services and/or allow them to be interworked between ISDN/SIP.

Joanne
  ----- Original Message ----- 
  From: Joanne McMillen 
  To: DRAGE, Keith (Keith) ; Elwell, John ; Alan Johnston ; [email-masked] 
  Sent: Thursday, December 11, 2008 6:52 AM
  Subject: Re: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

  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 ----- 
    From: DRAGE, Keith (Keith) 
    To: Elwell, John ; Joanne McMillen ; Alan Johnston ; [email-masked] 
    Sent: Thursday, December 11, 2008 4:56 AM
    Subject: RE: [Sipping] 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

--------------------------------------------------------------------------
      From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
      Sent: Thursday, December 11, 2008 7:34 AM
      To: Joanne McMillen; Alan Johnston; [email-masked]
      Subject: Re: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

      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

------------------------------------------------------------------------
        From: Joanne McMillen [mailto:[email-masked]] 
        Sent: 10 December 2008 22:30
        To: Elwell, John; Alan Johnston; [email-masked]
        Subject: Re: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

        in line...
          ----- Original Message ----- 
          From: Elwell, John 
          To: Alan Johnston ; Joanne McMillen ; [email-masked] 
          Sent: Tuesday, December 02, 2008 11:51 PM
          Subject: RE: [Sipping] 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: [email-masked] 
          > [mailto:[email-masked]] On Behalf Of Mary Barnes
          > Sent: 02 December 2008 00:49
          > To: [email-masked]
          > Cc: Gonzalo Camarillo
          > Subject: [Sipping] 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 
          > 
          > 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP