Subject: Re: [Sipping] [Fwd: New Version Notification fordraft-johnston-sipping-cc-uui-05]

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 1 Nov 2008 21:11:43 +0100

This reflects and resolves my comments made in Dublin.

In regard to the open issues:

      OPEN ISSUE: Should we allow multiple User-to-User header fields in
      SIP even though ISDN does not support this?  If so, we would need
      to provide guidance for a SIP to ISDN gateway for mapping, such as
      map the first header field and drop the rest.

My answer would be no. This is primarily intended for interworking with
the ISDN, and therefore there would be a high expectation that any
subsequent UUI data would be dropped.

      OPEN ISSUE: Is there an advantage in extracting the protocol
      discriminator and encoding in a header parameter?  What would a
      SIP UA do with this information?

Again no. It is important that the protocol discriminator is known to be
included in the data, but it is outside the SIP protocol, and therefore
we should not provide a SIP encoding for it.

I have one minor comment, I am not entirely convinced by requirement 7,
and therefore the need for an option tag. If I recall correctly the ISDN
implicit service is not guaranteed. If you want that guarantee, then you
need the explicit service.

NIT 1: The convention in DSS1 is to write an information element as Xyz
abc information element, i.e. only the first letter of the first word
capitalised.

NIT 2: Text 

   This section discusses four uses cases for the transport of call
   control related user to user information.  What is not discussed here
   is the transport of non-call control UUI which can be done using the
   SIP INFO method.  These use cases help explain the requirements from
   the previous section.

I would remove the reference to non-call control UUI, as firstly INFO as
in ISUP usage can contain call control information, and other methods
also exist apart from INFO for other information.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan Johnston
> Sent: Friday, October 31, 2008 8:18 PM
> To: sipping
> Cc: Joanne McMillen
> Subject: [Sipping] [Fwd: New Version Notification 
> fordraft-johnston-sipping-cc-uui-05]
> 
> 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 <[email-masked]>
> To: 	[email-masked]
> CC: 	[email-masked]
> 
> 
> 
> 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 [email-masked] for questions on current 
> sip Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 01 Nov 2008 22:08:57 -0400

DRAGE, Keith (Keith) wrote:

> the ISDN, and therefore ...

Keith, I don't understand this argument.

This only makes sense to me if the need for this functionality will only 
*ever* exist during ISDN interworking. And I don't believe that.

Step 0:

Two ISDN devices communicate using some feature that requires the UUI 
capability.

Step 1:

One of those devices is replaced by a SIP device. The SIP device needs 
to interwork with ISDN device, so it implements this feature in this 
ISDN interworking style.

Step 2:

The other ISDN device is replaced by a SIP device. It needs to interwork 
with the other SIP device using this ISDN interworking style.

Net result: the *native* SIP mechanism for this feature is via this 
opaque ISDN encoding, embodying limitations that are no longer meaningful.

Then it too painful to migrate to a more natural sip native mechanism.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Nov 2008 16:06:06 -0800

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.

I was also wondering if Q.1980.1 NSS pretty much solved this problem  
or if something more was needed.

Cullen <with my individual contributor hat on>

On Oct 31, 2008, at 13:17 , Alan Johnston wrote:

> Subject: 	New Version Notification for draft-johnston-sipping-cc- 
> uui-05
> 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.
>
> Title:		 Transporting User to User Call Control Information in SIP  
> for ISDN Interworking
> 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.
>
>
>
>
>

---

From: "Joanne McMillen" <[email-masked]>
Date: Wed, 12 Nov 2008 17:35:43 -0800

in line...
  ----- Original Message ----- 
  From: Cullen Jennings 
  To: Alan Johnston 
  Cc: sipping ; Joanne McMillen 
  Sent: Wednesday, November 12, 2008 4:06 PM
  Subject: Re: [Sipping] [Fwd: New Version Notification for draft-johnston-sipping-cc-uui-05]

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 Nov 2008 19:52:33 -0600

Cullen,

Thanks for your comments on the draft.  We tried very hard to be 
specific about the requirements in the draft - if any text is unclear, 
please let us know so we can clarify it.

Strictly speaking, this service is just between a UAC to a UAS as it is 
defined in ISDN.  I suspect the way it will be deployed with SIP will 
involve some proxy routing as well.

Tunneling NSS does not meet the requirements as discussed in the draft - 
if it did, we wouldn't need to do anything and everyone would be 
implementing that.

Thanks,
Alan

Cullen Jennings wrote:
>> Title:         Transporting User to User Call Control Information in 
>> SIP for ISDN Interworking

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 14 Nov 2008 13:56:12 +0100

Cullen, 

Within the Deutsche Telekom (fixed networks) we identified a strong need for UUI as a way to transport information within SIP messages UA-to-UA, UA-to-AS, AS-to-UA, AS-to-AS. We already have Alan's draft in the requirements for MGC and Application Servers. In the future we may have scenarios as described by Alan in the Use Case 4.3 Redirection, but this depends on the future product management requirements. 

My feeling is that Alan wonderfully catched the requirements. 

We will prefer the Header-Field approach because it is more flexible and covers the most use cases. I think there is the only way to fulfill the REQ-6 in the draft.   

The MIME-Body approach would cover our current needs, but probably will not cover the needs for products we will build within two or three years. In this case we will have to choose between replacing redirect servers with B2BUAs just to be able to use UUI or introducing some proprietary headers. I think this is what REQ-6 tries to avoid. 

Laura

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Nov 2008 07:55:07 -0800

I think the point is that some native SIP endpoints may want to use this UUI
capabilities, especially in a mixed network (some legacy/PSTN and some
native SIP). I believe Alan describes this in the document (if I'm not
mistaking).

That would argue for the Header approach.

Also, yes, I do believe that there will be cases where intermediaries would
look at the information. Again, Alan, tell me if I'm wrong.

On Nov14 2008 04:56 , "Liess, Laura" <[email-masked]> wrote:

> Cullen, 
> 
> Within the Deutsche Telekom (fixed networks) we identified a strong need for
> UUI as a way to transport information within SIP messages UA-to-UA, UA-to-AS,
> AS-to-UA, AS-to-AS. We already have Alan's draft in the requirements for MGC
> and Application Servers. In the future we may have scenarios as described by
> Alan in the Use Case 4.3 Redirection, but this depends on the future product
> management requirements.
> 
> We will prefer the Header-Field approach because it is more flexible and
> covers the most use cases. I think there is the only way to fulfill the REQ-6
> in the draft.   
> 
> The MIME-Body approach would cover our current needs, but probably will not
> cover the needs for products we will build within two or three years. In this
> case we will have to choose between replacing redirect servers with B2BUAs
> just to be able to use UUI or introducing some proprietary headers. I think
> this is what REQ-6 tries to avoid.
> 
> Laura
> 
>        
>  
>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 15 Nov 2008 15:03:11 -0700

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:

> 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
> Most folks I have talked to about NSS have two responses - an  
> irritated sigh with eyeball roll is the nice one.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 16 Nov 2008 08:15:27 +0100

Can I just note that this is not really an ISDN parameter.

The ISDN parameter is an envelope and information passed into SIP is the
contents of the envelope, which can be any of a number of different
protocols as indicated by the protocol discriminator.

I do agree that the main justification for its existence is to allow
interworking with the legacy ISDN usages of the same parameter.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Saturday, November 15, 2008 10:03 PM
> To: Joanne McMillen; Alan Johnston
> Cc: sipping
> Subject: [Sipping] draft-johnston-sipping-cc-uui-05
> 
> 
> 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.
> 
> > 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
> > [Joanne] Oh come on Cullen - we both know the answer to 
> that. Yes - if 
> > you want a tunneling solution.
> > > A new version of I-D, 
> draft-johnston-sipping-cc-uui-05.txt has been 
> > > Title: Transporting User to User Call Control Information 
> in SIP for 
> > > ISDN Interworking
> approaches and 
> > > 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
> >
> > 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: Cullen Jennings <[email-masked]>
Date: Sun, 16 Nov 2008 06:39:59 -0600

Good point - I should have been more specific.

---

From: Alan Johnston <[email-masked]>
Date: Mon, 17 Nov 2008 10:22:12 -0600

Cullen,

Keith is correct - this is not about mapping ISDN parameters into SIP, 
it is about mapping a very successful and popular ISDN *service* into 
SIP.  Until we solve this with an appropriate mechanism, SIP will not 
make headway into areas such as contact centers.

And, there is a limit on the size of data - please read the draft.

And the draft says nothing about proxy inspection and routing.  I 
mentioned it in my email because we know that clever implementors will 
do clever things.

The draft is not making the arguments you specify.

So, if I remove the text in your comments about this being an ISDN 
parameter mapping issue, the size being unlimited, and problematic proxy 
behavior, I don't think there are any remaining issues.

If you have issues with the requirements in the draft, let us know so we 
can clarify them.

Thanks,
Alan

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Nov 2008 18:28:41 -0600

On Nov 17, 2008, at 10:22 , Alan Johnston wrote:

> SIP.
Fair enough - I agree with you and Keith on this.

> Until we solve this with an appropriate mechanism, SIP will not

Hmm - you are right that when I read it, I had missed the key part of

    Note that ISDN limits UUI to 128 octets in length.  While this  
header
    field has no such limitations, transporting UUI longer than 128
    octets will result in interoperability failures when interworking
    with ISDN.

> If you have issues with the requirements in the draft, let us know  
I can easily imagine cases where customer sensitize information was  
transfered over this and it was going to an remote agent phone that  
went through another trust domain to route the call to the agent. In  
these cases, I think an important requirement would be to  protect the  
draft from authorized access by intermediaries.

Cullen in my individual contributor role

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Nov 2008 19:57:01 -0500

> Fair enough - I agree with you and Keith on this.

This is precisely my concern. By doing this we are adopting this syntax 
for carrying data for what will eventually be *SIP* services. Is this 
*really* the way we want to support those services in a native sip 
environment?

Once its done it will not make sense to develop a different syntax for 
native sip use.

If we go this way, every sip entity that needs to deal with these will 
need to have the needed ASN.1 encoding/decoding logic. I don't know if 
that is trivial to special case because I don't know what all the 
various formats are. But it would at least be annoying.

	Thanks,
	Paul

>    Note that ISDN limits UUI to 128 octets in length.  While this header
> transfered over this and it was going to an remote agent phone that went 
> through another trust domain to route the call to the agent. In these 
> cases, I think an important requirement would be to  protect the draft 
> from authorized access by intermediaries.
> 
>>
>

---

From: James Rafferty <[email-masked]>
Date: Thu, 20 Nov 2008 10:42:01 -0500

I'd like to support this draft moving ahead for standardization. Our company has done an implementation of an earlier version of the draft in a media gateway and the feature has been very popular among customers.

The primary use case has been for collecting user information transported over the ISDN network and bringing it into a SIP-based call center using the proposed SIP header. However, there are other use cases being considered, all of which build on the existing ISDN UUE supplementary service.  We have not had any interoperability issues.  If the implementers understand how the UUI data is being used for the ISDN service, decoding it for use in the SIP environment has not posed a problem.

We also support facilities such as SIP-T in our gateways which can support ISUP / ISDN content as MIME attachments, but most SIP implementers do not support these MIME extensions, so the UUI header is a valuable addition.

I have a couple of responses on comments below from Paul(see JR).

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, November 19, 2008 7:57 PM
To: Cullen Jennings
Cc: DRAGE, Keith (Keith); Joanne McMillen; sipping
Subject: Re: [Sipping] draft-johnston-sipping-cc-uui-05

JR - This draft is not about creating a new SIP service, but rather interoperating with the existing UUE service in ISDN.

JR - Why not?  If the service is valuable in gateways, it may also be valuable in the pure SIP environment, but a new service would not need to be backward compatible with ISDN syntax.

JR - Since the draft's focus is on interoperating with ISDN, the binary format is defined in Q.931 and an implementer that wants to decode it will have such a facility. The actual semantics of the data depend upon the use case.

        Thanks,
        Paul

---

From: "Laura Liess" <[email-masked]>
Date: Thu, 20 Nov 2008 18:03:43 +0100

> *really* the way we want to support those services in a native sip 

Paul,
I do not see why we should not do both and leave the decision to the market. 
IETF did this in the past.

    1) Get this syntax agreed as soon as possible because it is needed by 
the industry in the today's PSTN/SIP mixed environment. If we do not come up 
very soon with a standard, people will use proprietary extenssions. I think 
we should avoid this. There are no technical reasons not to move on with the 
draft.

    2) In the long term we could develop a "native sip" syntax which is more 
flexible, easier to implement, whatever.... It will have advantages in a 
"sip native" environment and it will be adopted when the "native sip" 
environement is in place.

Laura

> that is trivial to special case because I don't know what all the various 
> formats are. But it would at least be annoying.
>
> Thanks,
> Paul
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 20 Nov 2008 11:37:42 -0800

> the industry in the today's PSTN/SIP mixed environment.

Well, I have here to make the observation that SIP-PSTN is not the only mixed environment.
SIP is also used on IP networks and on the Internet and the UUI may look there vastly more different - probably extensible and very powerful. And it may be just as urgent.

So it appears the SIP UUI may end up with two tracks, one for compatibility with ISDN and the other for the IP networks and the Internet.

What do the authors think?

Henry

Paul,

Laura

---

From: "Joanne McMillen" <[email-masked]>
Date: Thu, 20 Nov 2008 13:17:19 -0800

I can tell you what one author thinks Henry. ;-)

Like Laura and others have stated - we have an immediate need here.

Where this may go in the future with enhanced definitions in SIP is  future consideration.

We all agree (I suspect) that SIP can be far more robust here for this "functionality".
When and if someone wants to define what that new and robust "functionality" is in SIP
it would beg the question as to whether or not this specific header for UUI is the right avenue for that.
It could be and it couldn't be - I can see that debate going either way and for very good reasons
for going either way. The bottom line is we have an immediate need right now that this draft addresses - I do not want to see this
get bogged down by future concerns - and the definition allows for that if anyone chooses to extend it
going forward in SIP...

Can we eliminate the "futures" discussion here for that "other track" and just deal with the immediate need please?

Thanks,
Joanne

  ----- Original Message ----- 
  From: Henry Sinnreich 
  To: Laura Liess ; Cullen Jennings ; Paul Kyzivat 
  Cc: sipping ; Joanne McMillen ; DRAGE, Keith (Keith) ; Huelsemann, Martin 
  Sent: Thursday, November 20, 2008 11:37 AM
  Subject: Re: [Sipping] draft-johnston-sipping-cc-uui-05

  Henry

  Paul,

  Laura

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 20 Nov 2008 13:20:43 -0800

Joanne,

>Can we eliminate the "futures" discussion here for that "other track" and just deal with the immediate need please?

This is new to me: IP networks (such as inside contact centers, enterprises) and the Internet are futures? :-)

But I do not intend to press this any further.

Henry

On 11/20/08 1:17 PM, "Joanne McMillen" <[email-masked]> wrote:

Thanks,
Joanne

----- Original Message -----

From:  Henry  Sinnreich <mailto:[email-masked]>

To: Laura Liess <mailto:[email-masked]>  ; Cullen Jennings <mailto:[email-masked]>  ; Paul Kyzivat <mailto:[email-masked]>

Cc: sipping <mailto:[email-masked]>  ; Joanne McMillen <mailto:[email-masked]>  ; DRAGE,  Keith (Keith) <mailto:[email-masked]>  ; Huelsemann, Martin <mailto:[email-masked]>

Henry

Paul,

Laura

---

From: "Joanne McMillen" <[email-masked]>
Date: Thu, 20 Nov 2008 14:22:24 -0800

in line...
  ----- Original Message ----- 
  From: Henry Sinnreich 
  To: Joanne McMillen ; Paul Kyzivat ; Cullen Jennings ; Laura Liess 
  Cc: Huelsemann, Martin ; DRAGE, Keith (Keith) ; sipping 
  Sent: Thursday, November 20, 2008 1:20 PM
  Subject: Re: [Sipping] draft-johnston-sipping-cc-uui-05

  Joanne,

  [Joanne] Heck no - "futures"  functionality of what UUI is intended to provide in this draft as you stated "on the  Internet and the UUI may look there vastly more different - probably  extensible and very powerful. And it may be just as urgent"...
  That is "futures" for this draft... 
  Your point was indeed acknowledged - I don't think anyone at all disagrees with it - we
  all know that - it just is not the immediate need covered in this draft that industry needs to move forward with - now.

  Henry

  Thanks,
  Joanne

  ----- Original Message -----

  Henry

  Paul,

  Laura

---

From: Alan Johnston <[email-masked]>
Date: Thu, 20 Nov 2008 17:17:19 -0600

Cullen Jennings wrote:
> <snip>
Cullen,

Here's the text from the Security Considerations section of the draft - 
let me know if it is not sufficient:

   In some cases, it [UUI] may carry private information
   that may need confidential transport and integrity protection.
   Standard SIP security mechanisms can be used to secure this header
   field.  For example, TLS transport can provide single hop
   confidentiality and integrity protection.  For multiple hop or end-
   to-end confidentiality and integrity protection, S/MIME can be
   utilized.

Thanks,
Alan

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 20:29:26 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cullen Jennings
>

Do you mean protect it from unauthorized access?  Or allow for authorized access? (and I assume you mean the UUI data, not protect the "draft" ;)

I don't think there's anything you can do to stop tampering or reading it, without pre-shared keys or certs of course.  And middleboxes can already read and modify ISUP mime bodies so it's not any worse really.

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Nov 2008 06:27:46 +0100

So to Henry - what protocols other than those carried by ISDN did you
want to map over SIP.

I would argue that in an entirely SIP environment, this would be either
using SIP as a transport protocol, and therefore incorrect, or that the
mechanisms already exist in such an environment for carry things like
MESSAGE which solve this problem.

The ISDN issue is that this transport is already embedded in a call
control message, and therefore by splitting it out, you would lose the
coupling semantic that exists in the ISDN protocol. Therefore ISDN has
an interworking case where there is a need to do this. 

Does the interworking with any other protocol generate such a need where
we could see the need to extend the current requirements.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Henry Sinnreich
> Sent: Thursday, November 20, 2008 9:21 PM
> To: Joanne McMillen; Paul Kyzivat; Cullen Jennings; Laura Liess
> Cc: sipping; DRAGE, Keith (Keith); Huelsemann,Martin
> >Can we eliminate the "futures" discussion here for that 
> "other track" and just deal with the immediate need please?
> 
> This is new to me: IP networks (such as inside contact 
> centers, enterprises) and the Internet are futures? :-)
> 
> When and if someone wants to define what that new and robust 
> "functionality" is in SIP it would beg the question as to 
> whether or not this specific header for UUI is the right 
> avenue for that.
> It could be and it couldn't be - I can see that debate going 
> either way and for very good reasons for going either way. 
> The bottom line is we have an immediate need right now that 
> this draft addresses - I do not want to see this get bogged 
> down by future concerns - and the definition allows for that 
> if anyone chooses to extend it going forward in SIP...
> 
> Can we eliminate the "futures" discussion here for that 
> "other track" and just deal with the immediate need please?
> 
> Thanks,
> Joanne
> 
> 
> To: Laura Liess <mailto:[email-masked]>  ; Cullen 
> Jennings <mailto:[email-masked]>  ; Paul Kyzivat 
> <mailto:[email-masked]>
> 
> Cc: sipping <mailto:[email-masked]>  ; Joanne McMillen 
> <mailto:[email-masked]>  ; DRAGE,  Keith (Keith) 
> <mailto:[email-masked]>  ; Huelsemann, Martin 
> <mailto:[email-masked]>
> 
> >  1) Get this syntax agreed as soon as possible  because it 
> is needed 
> > by the industry in the today's PSTN/SIP mixed  environment.
> 
> SIP is also used on IP networks and on the  Internet and the 
> UUI may look there vastly more different - probably  
> extensible and very powerful. And it may be just as urgent.
> 
> So it  appears the SIP UUI may end up with two tracks, one 
> for compatibility with  ISDN and the other for the IP 
> networks and the Internet.
> 
> > This is precisely my concern. By doing this we are  adopting this 
> > syntax for carrying data for what will eventually be  *SIP* 
> services. 
> > Is this
>     1) Get this syntax agreed as soon as  possible because it 
> is needed by the industry in the today's PSTN/SIP mixed  
> environment. If we do not come up very soon with a standard, 
> people will  use proprietary extenssions. I think we should 
> avoid this. There are no  technical reasons not to move on 
> with the draft.
> 
>      2) In the long term we could develop a "native sip" 
> syntax which is  more flexible, easier to implement, 
> whatever.... It will have advantages in  a "sip native" 
> environment and it will be adopted when the "native  sip"
> > Once  its done it will not make sense to develop a different syntax 
> > for  native sip use.
> >
> > If we go this way, every sip entity that needs  to deal with these 
> > will need to have the needed ASN.1  encoding/decoding 
> logic. I don't 
> > know if that is trivial to special  case because I don't 
> know what all 
> > the various formats are. But it  would at least be annoying.
> >
> > Thanks,
> >  Paul
> >
> >>  Hmm - you are right that when I read it, I had missed the 
> key part  
> >> of
> >>
> >>> mentioned it in my email because we know that clever 
> implementors  
> >>> will do clever things.
> >>>
> >>> parameter mapping issue, the size being unlimited, and  
> problematic 
> >>> proxy behavior, I don't think there are any  remaining issues.
> >>>
> >>> If you have issues with the  requirements in the draft, 
> let us know 
> >>> so we can clarify  them.
> >>>
> >> these cases, I think an important  requirement would be to 
>  protect 
> >> the draft from authorized  access by intermediaries.
> >>
> >>>
> >>
> Use [email-masked]  for questions on 
> current sip Use [email-masked] for new developments of core  SIP
> 
>

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 21 Nov 2008 06:45:19 -0800

Keith,

>what protocols other than those carried by ISDN did you
>want to map over SIP.

This is a good question and allows me to clarify two points:

 *   Since the I-D <draft-johnston-sipping-cc-uui>  is solving a real problem for some people, it should be published as an informational RFC ASAP. Far too much design by committee has already been perpetrated :-)

 *   As for what other protocols to map over SIP, please recall our I-D on "simple SIP": The option to use SIP only for rendezvous and session setup negotiation. Simple SIP solves we believes this (send data along with a call transfer) and other requirements as well over IP networks and over the Internet.

Henry

On 11/20/08 9:27 PM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

regards

Keith

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 23 Nov 2008 21:27:53 +0100

To publish as informational under the current IANA registration procedures would mean that the solution would need to be downgraded to a P-header, and the option tag would need to be removed. The option tag is there to meet one of the ISDN interworking requirements, as it is possible to say in DSS1 that the call should only proceed in the UUI is understood - i.e. interworking capability will be lost.

Do others share Henry's view, or should this document ultimately proceed in SIP as a standards track document, with the proposed new header field and option tag.

regards

Keith 

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Friday, November 21, 2008 2:45 PM
> To: DRAGE, Keith (Keith); Joanne McMillen; Paul Kyzivat; 
> Cullen Jennings; Laura Liess
> Cc: sipping; Huelsemann,Martin
> >what protocols other than those carried by ISDN did you want to map 
> >over SIP.
> 
>  *   Since the I-D <draft-johnston-sipping-cc-uui>  is 
> solving a real problem for some people, it should be 
> published as an informational RFC ASAP. Far too much design 
> by committee has already been perpetrated :-)
> 
> 
>  *   As for what other protocols to map over SIP, please 
> recall our I-D on "simple SIP": The option to use SIP only 
> for rendezvous and session setup negotiation. Simple SIP 
> solves we believes this (send data along with a call 
> transfer) and other requirements as well over IP networks and 
> over the Internet.
> 
> Henry
> 
> 
> So to Henry - what protocols other than those carried by ISDN 
> did you want to map over SIP.
> 
> I would argue that in an entirely SIP environment, this would 
> be either using SIP as a transport protocol, and therefore 
> incorrect, or that the mechanisms already exist in such an 
> environment for carry things like MESSAGE which solve this problem.
> 
> The ISDN issue is that this transport is already embedded in 
> a call control message, and therefore by splitting it out, 
> you would lose the coupling semantic that exists in the ISDN 
> protocol. Therefore ISDN has an interworking case where there 
> is a need to do this.
> 
> Does the interworking with any other protocol generate such a 
> need where we could see the need to extend the current requirements.
> 
> regards
> 
> Keith
> 
> > This is new to me: IP networks (such as inside contact centers, 
> > enterprises) and the Internet are futures? :-)
> >
> > Where this may go in the future with enhanced definitions 
> in SIP is  
> > future consideration.
> >
> > We all agree (I suspect) that SIP can be far more robust 
> here for this 
> > "functionality".
> whether or 
> > not this specific header for UUI is the right avenue for that.
> > It could be and it couldn't be - I can see that debate going either 
> > way and for very good reasons for going either way.
> this draft 
> > addresses - I do not want to see this get bogged down by future 
> > concerns - and the definition allows for that if anyone chooses to 
> > extend it going forward in SIP...
> >
> "other track" 
> > and just deal with the immediate need please?
> >
> > Thanks,
> > Joanne
> >
> >
> > To: Laura Liess <mailto:[email-masked]>  ; Cullen Jennings 
> > <mailto:[email-masked]>  ; Paul Kyzivat 
> > SIP is also used on IP networks and on the  Internet and 
> the UUI may 
> > look there vastly more different - probably extensible and very 
> > powerful. And it may be just as urgent.
> >
> > So it  appears the SIP UUI may end up with two tracks, one for 
> > compatibility with  ISDN and the other for the IP networks and the 
> > Internet.
> >
> > I do not see why  we should not do both and leave the 
> decision to the 
> > market.
> >     1) Get this syntax agreed as soon as  possible because it is 
> > needed by the industry in the today's PSTN/SIP mixed 
> environment. If 
> > we do not come up very soon with a standard, people will  use 
> > proprietary extenssions. I think we should avoid this. 
> There are no  
> > technical reasons not to move on with the draft.
> >

---

From: "Mary Barnes" <[email-masked]>
Date: Sun, 23 Nov 2008 14:45:58 -0600

Keith,

Gonzalo and I did synch up with Alan and Cullen after the meeting to
resolve the debate we (chairs) were having at the end of the discussion,
as I realize we (I) did introduce some confusion on the way forward. 

The proposal is that this doc would go through WGLC in SIPPING (there
was a hum for support of progressing this doc during the session) -
pending Jon's approval of a new milestone. Progression of the document
would be in the form of the problem statement and requirements only (as
Informational). SIP WG would work from the requirements to
develop/complete the solution - again pending agreement in SIP WG. 

The plan is to do a pre-WGLC of the document in SIPPING to determine
readiness ASAP.  At this point, there were no concerns (on the
requirements) raised in the meeting, so folks should raise any ASAP. 

Regards,
Mary. 

Note: I've snipped the "to"s and "cc"s, adding Alan and Jon and also
snipped the thread, as it was getting quite long.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
Sent: Sunday, November 23, 2008 2:28 PM
To: Henry Sinnreich; Joanne McMillen; Paul Kyzivat; Cullen Jennings;
Laura Liess
Cc: sipping; Huelsemann,Martin
Subject: Re: [Sipping] draft-johnston-sipping-cc-uui-05

To publish as informational under the current IANA registration
procedures would mean that the solution would need to be downgraded to a
P-header, and the option tag would need to be removed. The option tag is
there to meet one of the ISDN interworking requirements, as it is
possible to say in DSS1 that the call should only proceed in the UUI is
understood - i.e. interworking capability will be lost.

Do others share Henry's view, or should this document ultimately proceed
in SIP as a standards track document, with the proposed new header field
and option tag.

regards

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Nov 2008 16:53:00 -0700

On Nov 20, 2008, at 6:29 PM, Hadriel Kaplan wrote:

> Do you mean protect it from unauthorized access?

sorry - yes I mean unauthorized not authorized - it was a long week.

---

From: Alan Johnston <[email-masked]>
Date: Sun, 23 Nov 2008 18:57:11 -0600

I do not want a P-header.  It would not meet the requirements of the 
industry.

I do think, however, that we can finish this work quickly (unless our 
process breaks down completely).  I mean, these are simple, simple 
requirements.

If others such as Henry want a more expansive mechanism for application 
users of SIP, then it would be interesting to start work on new 
requirements in SIPPING and see where it takes us.  However, this work 
is clearly separate - one should not hold up the other.

Thanks,
Alan

DRAGE, Keith (Keith) wrote:
>>>> *really* the way we want to support those  services in a 
>>>>         
>> native sip 
>>     
>>>> environment?
>>>>         
>>> Paul,
>> whatever.... It 
>>> will have advantages in  a "sip native"
>>>> Once  its done it will not make sense to develop a 
>>>>         
>> different syntax 
>>     
>>>> for  native sip use.
>>>>
>>>> If we go this way, every sip entity that needs  to deal 
>>>>         
>> with these 
>>     
>>>>>> Until we solve this with an appropriate  mechanism, SIP 
>>>>>>             
>> will not 
>>     
>>>>>> And, there is a limit on the  size of data - please read
>>>>>>             
>>> the draft.
>>>       
>>>>>    Note that ISDN limits UUI to 128  octets in length.
>>>>>           
>>> While this header
>>>       
>>>>>    field  has no such limitations, transporting UUI longer
>>>>>           
>>> than  128
>>>       
>>>>>    octets will result in interoperability  failures when
>>>>>           
>>> interworking
>>>       
>>>>>    with  ISDN.
>>>>>
>>>>>           
>>>>>> And the  draft says nothing about proxy inspection and
>>>>>>             
>>> routing.  I
>>>       
>>>>>>  So, if I remove the text in your comments about this
>>>>>>             
>>> being an  ISDN
>>>       
>>>>> I can easily imagine cases where customer  sensitize
>>>>>           
>>> information was
>>>       
>>>>> transfered over this and it was going to  an remote agent
>>>>>           
>>> phone that
>>>       
>>>>> went through another trust domain to  route the call to
>>>>>           
>>> the agent. In
>>>       
>>>>> [email-masked]  for questions on 
>>>>>           
>> current sip Use 
>>     
>>>> [email-masked]  for questions on 
>>>>         
>> current sip Use 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 11:53:57 -0500

DRAGE, Keith (Keith) wrote:
> To publish as informational under the current IANA registration procedures would mean that the solution would need to be downgraded to a P-header, and the option tag would need to be removed. 
> The option tag is there to meet one of the ISDN interworking requirements, as it is possible to say in DSS1 that the call should only proceed in the UUI is understood - i.e. interworking capability will be lost.

Is the requirement that the call should only proceed if the overall UUI 
transport mechanism is understood? Or only if the particular UUI type is 
understood? (I got the impression from earlier discussion in this thread 
that each of those types has an independent usage.)

If its important that the particular type be understood, then one option 
tag doesn't seem sufficient to get the desired effect.

	Thanks,
	Paul

---

From: "Liess, Laura" <[email-masked]>
Date: Mon, 24 Nov 2008 17:59:51 +0100

Keith, 

I agree with Alan. We also prefer a standards track document, with the proposed new header field and option tag, if it does not take years until we have a stable syntax so people can implement it. 

Regards
Laura

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Sonntag, 23. November 2008 21:28
An: Henry Sinnreich; Joanne McMillen; Paul Kyzivat; Cullen Jennings; Laura Liess
Cc: sipping; Hülsemann, Martin
Betreff: Re: [Sipping] draft-johnston-sipping-cc-uui-05

regards

Keith

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Nov 2008 02:38:38 +0100

I just relooked at the ISDN documents, and it is only user-to-user service 1 explicit requests that carry the required as opposed to preferred indicator. 

My understanding was that we were only interworking with user-to-user service 1 implicit and therefore the option tag would not be required for this. 

Note that the the required versus preferred information in DSS1 and QSIG is carried in the Facility information element and not in the DSS1/QSIG User-user information element. In ISUP it is carried in the the user-to-user indicators parameter with service 1 indicated as "requested, essential" and the data itself is in the user-to-user information parameter.

Currently I know of no interworking specification attempting to use the proposed User-to-User header field that additionally maps the user-to-user indicators parameter from ISUP.

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, November 24, 2008 4:54 PM
> To: DRAGE, Keith (Keith)
> Cc: Henry Sinnreich; Joanne McMillen; Cullen Jennings; Laura 
> Liess; sipping; Huelsemann,Martin
> > To publish as informational under the current IANA 
> registration procedures would mean that the solution would 
> need to be downgraded to a P-header, and the option tag would 
> need to be removed. 
> > The option tag is there to meet one of the ISDN 
> interworking requirements, as it is possible to say in DSS1 
> that the call should only proceed in the UUI is understood - 
> i.e. interworking capability will be lost.
> 
> Is the requirement that the call should only proceed if the 
> overall UUI transport mechanism is understood? Or only if the 
> particular UUI type is understood? (I got the impression from 
> earlier discussion in this thread that each of those types 
> has an independent usage.)
> 
> If its important that the particular type be understood, then 
> one option tag doesn't seem sufficient to get the desired effect.
> 
> 	Thanks,
> 	Paul
> 
>

---

From: Lili Yang <[email-masked]>
Date: Tue, 25 Nov 2008 12:03:31 +0800

Keith, all,
I also support it as a standards track document. Since the header has been
used in CSI stage3 TS 24.279, it's beneficial to have a stable syntax. 

Regards
Lili 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Liess, Laura
Sent: Tuesday, November 25, 2008 1:00 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Huelsemann, Martin
Subject: Re: [Sipping] draft-johnston-sipping-cc-uui-05

Keith, 

I agree with Alan. We also prefer a standards track document, with the
proposed new header field and option tag, if it does not take years until we
have a stable syntax so people can implement it. 

Regards
Laura

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von DRAGE, Keith (Keith)
Gesendet: Sonntag, 23. November 2008 21:28
An: Henry Sinnreich; Joanne McMillen; Paul Kyzivat; Cullen Jennings; Laura
Liess
Cc: sipping; Hülsemann, Martin
Betreff: Re: [Sipping] draft-johnston-sipping-cc-uui-05

To publish as informational under the current IANA registration procedures
would mean that the solution would need to be downgraded to a P-header, and
the option tag would need to be removed. The option tag is there to meet one
of the ISDN interworking requirements, as it is possible to say in DSS1 that
the call should only proceed in the UUI is understood - i.e. interworking
capability will be lost.

Do others share Henry's view, or should this document ultimately proceed in
SIP as a standards track document, with the proposed new header field and
option tag.

regards

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Nov 2008 12:31:58 -0700

I was just trying to help this not get bogged down.

>    to-end confidentiality and integrity protection, S/MIME can be

Uh, I can understand how S/MIME protects a body but seems like a bit  
more might be needed to explain how it protects a header.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 27 Nov 2008 13:00:31 -0600

> more might be needed to explain how it protects a header.

Is the text in RFC 3261 not clear?

    23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP

If not, I doubt this draft is the right place to clarify it, but perhaps 
in another draft.

Thanks,
Alan

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Nov 2008 13:39:43 -0700

So you want the new header to be tunneled in a body part of the SIP  
message?