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

From: "Mary Barnes" <[email-masked]>
Date: Mon, 1 Dec 2008 18:49:15 -0600

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

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Dec 2008 07:51:20 +0000

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. 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
- 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>  
> 
> 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 
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Dec 2008 02:30:04 +0100

I was generally OK with this document, but I would still like to see a response on my last comments on the use of the option tag, and the associated requirement clause that causes us to need it.

Essentially if the aim of the document is only to interwork with the ISDN user-to-user service 1 implicit, then we don't need the option tag.

If the aim of the document is to interwork with the ISDN user-to-user service 1 explicit, then we would need the option tag in a Require header, I think we need to make sure of a number of things:

-    as all ISDN user user services can be separately explicit, is this going to ultimately generate 3 option tags.
-    have we collected all the requirements for interworking with the explicit service, which requires interworking with explicit signalling in the ISDN. In particular are there any distinct response code requirements.

If the aim of the document is only to interwork with the ISDN user-to-user service 1 implicit, but there are other use cases that require the option-tag, then I think the document should be open about these so we can examine the requirements in the light of those other use cases.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Tuesday, December 02, 2008 12:49 AM
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

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 9 Dec 2008 14:41:49 -0600

Initial WG review: draft-johnston-sipping-cc-uui-06

Summary: I believe this draft (especially the requirements section in this 
draft, which I think is what matters) is in good enough shape to send to SIP 
for protocol specification work.

Comments: I had a couple of questions (below), that do not affect readiness 
to send to SIP, and a couple of nits if the draft is revised for 
publication.

5.1.  Why INFO is Not Used

   Since the INFO method [RFC2976]., was developed for ISUP interworking

Spencer (nit): s/.,//

   of user-to-user information, it might seem to be the logical choice
   here.  For non-call control user-to-user information, INFO can be
   utilized for end to end transport.  However, for transport of call
   control user-to-user information, INFO can not be used.  As the call
   flows in the previous section show, the information is related to an
   attempt to establish a session and must be passed with the session
   setup request (INVITE), responses to that INVITE, or session
   termination requests.  As a result, it is not possible to use INFO in
   these cases.

5.3.  URI Parameter

   Another proposed approach is to encode the UUI as a URI parameter
   into the Contact or Refer-To URI.

  <allOneLine>
  Contact: <sip:[email-masked];uui=ZeGl9i2icVqaNVailT6
  F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
  </allOneLine>

   An INVITE sent to this Contact URI would contain UUI in the Request-
   URI of the INVITE.  The URI parameter has a drawback in that a URI
   parameter will not survive retargeting by a proxy as shown in Figure
   2.  That is, if the URI is included with an Address of Record instead
   of a Contact URI, the URI parameter will not be copied over to the
   Contact URI, resulting in the loss of the information.  As a result,
   this approach does not meet REQ-4.

Spencer: does the Refer-To URI have the same problem here?

5.4.  Header Field Approach

      Call-Info usually contains a URI pointer the information instead
      of the actual information itself which does not REQ-5.  It could

Spencer (nit): s/not/not meet/

      be possible to use a data URI to carry the UUI directly in this
      header field.

7.  Appendix - Syntax for UUI Header Field

   Current usage is to interoperate with ISDN User to User Signaling
   (UUS), a supplementary service in which manufacturer specific
   information is transported via the codeset 0 User-user Information
   IE.  Three services are defined: service 1, service 2, and service 3.
   This draft only addresses the SIP equivalent of service 1 although it
   could easily be expanded later to address services 2 and 3.  UUS
   Service 1 involves user to user signaling exchanged during call setup

Spencer (nit): s/user to user/user-to-user/

   and clearing within the following Q.931 call control messages: SETUP,
   ALERT, CONNECT, DISCONNECT, RELEASE, and RELEASE COMPLETE.  UUS
   Service 2 involves user to user signaling exchanged during call
   establishment (between ALERT and CONNECT) via the USER INFORMATION
   message.  This service usually has a maximum of 2 USER INFORMATION
   messages in each direction.  UUS Service 3 involves user to user
   signaling exchanged on an active call via the USER INFORMATION
   message.

8.  Security Considerations

   Received User-to-User information should only be trusted if it is
   authenticated or received within a trust domain.  For example,

Spencer: is "authenticated within a trust domain" sufficient? (I'm not quite 
sure how you know that you've received UUI within a trust domain, so I may 
not have understood what you're saying here.

   Spec-T, defined in [RFC3324] could be used to define a trust domain.
   When utilized by a gateway to map information to or from ISDN Q.931,
   appropriate policy should be applied based on the PSTN trust domain.

---

From: "Joanne McMillen" <[email-masked]>
Date: Wed, 10 Dec 2008 14:29:30 -0800

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,

  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...

  John

---

From: "Joanne McMillen" <[email-masked]>
Date: Wed, 10 Dec 2008 14:38:37 -0800

Initial WG review: draft-johnston-sipping-cc-uui-06Keith,

You raise an interesting point here. The immediate need of the industry so far as I know
is only for the implicit service.

Others can respond if they feel a need to have explicit functionality and the resulting response code/procedures
defined here for this first RFC. My guess is that we do not need it and should just
state that up front as beyond scope. I have not seen explicit support widely used in ISDN networks to date.
I could be wrong and live in a cave though. ;-)

What do others think? Should we account for that in this first RFC or just rule it out
and save "explicit" support for a future update as needed?

Joanne

  ----- Original Message ----- 
  From: DRAGE, Keith (Keith) 
  To: Mary Barnes ; [email-masked] 
  Cc: Gonzalo Camarillo 
  Sent: Thursday, December 04, 2008 5:30 PM
  Subject: Re: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

  regards

  Keith

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
    Sent: Tuesday, December 02, 2008 12:49 AM
    To: [email-masked]
    Cc: Gonzalo Camarillo
    Subject: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

    Hi folks, 

    Regards, 
    Mary. 
    SIPPING WG co-chair 

------------------------------------------------------------------------------

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Dec 2008 07:33:54 +0000

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 <mailto:[email-masked]>  
		To: Alan Johnston <mailto:[email-masked]>  ; Joanne
McMillen <mailto:[email-masked]>  ; [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

		> This email is intended to announce an initial WG
review for 
http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-
		> uui-06.txt

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 11 Dec 2008 13:56:19 +0100

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

in line...
----- Original Message -----
From: Elwell, John<mailto:[email-masked]>
To: Alan Johnston<mailto:[email-masked]> ; Joanne McMillen<mailto:[email-masked]> ; [email-masked]<mailto:[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,

John

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: Gonzalo Camarillo

---

From: Alan Johnston <[email-masked]>
Date: Thu, 11 Dec 2008 08:12:03 -0600

Spencer,

Thanks very much for your review.   We will fix the nits you found.  A 
few comments below.

Thanks,
Alan

Spencer Dawkins wrote:
> Summary: I believe this draft (especially the requirements section in 
> this draft, which I think is what matters) is in good enough shape to 
> send to SIP for protocol specification work.
>
> Comments: I had a couple of questions (below), that do not affect 
> readiness to send to SIP, and a couple of nits if the draft is revised 
> for publication.
>

Let me see if I understand your question.  Are you asking if we had a 
Refer-To header field in a REFER like:

 <allOneLine>
 Refer-To: <sip:[email-masked];uui=ZeGl9i2icVqaNVailT6
 F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
 </allOneLine>

Would the UUI get lost after proxy retargeting of the resulting INVITE?

The answer is yes - the problem applies here, too.

> Spencer: is "authenticated within a trust domain" sufficient? (I'm not 
> quite sure how you know that you've received UUI within a trust 
> domain, so I may not have understood what you're saying here.

This is confusing.  I agree that "authenticated within a trust domain" 
doesn't make sense.  We will clarify the sentence to:

  Received User-to-User information should only be trusted if it is
  authenticated or if it is received within a trust domain.

As for how you tell if you have received it within a trust domain, I 
believe a typical Spec-T will say that message content is trusted if it 
is received in an authenticated message from a member of your trust domain.

---

From: "Joanne McMillen" <[email-masked]>
Date: Thu, 11 Dec 2008 06:52:43 -0800

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

  regards

  Keith

    Joanne,

    John

--------------------------------------------------------------------------

      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,

        John

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 11 Dec 2008 20:04:00 +0100

But the key point I am making is that this method of operation is not what is defined for ISDN (at least at the internation level).

That at least needs to be brought out in the document as being a totally new non-ISDN use case.

You also have not addressed the point that if user A includes UUI, in ISDN they have an expectation of that being delivered to C, and it may form an integral part in establishing the call, even if not required in the absolute sense of the word. Does B just remove this UUI in your redirection proposal, so it can include its own UUI? Remember we have a limitation of only one UUI according to the current proposals.

regards

Keith

________________________________
From: Joanne McMillen [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 2:53 PM
To: DRAGE, Keith (Keith); Elwell, John; Alan Johnston; [email-masked]
Subject: Re: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06

Keith,

Jo

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

regards

Keith

Joanne,

John

in line...
----- Original Message -----
From: Elwell, John<mailto:[email-masked]>
To: Alan Johnston<mailto:[email-masked]> ; Joanne McMillen<mailto:[email-masked]> ; [email-masked]<mailto:[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,

John