Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Jul 2009 19:10:13 -0400

Hi Alan,

I took a quick look at this doc and the requirements doc as well. I have 
a few thoughts:

 From section 1:

>    In the future, where both endpoints are intelligent SIP user agents,
>    it may be possible for them to understand and interpret the UUI data.
>    There may be some cases where the UUI information is relevant to SIP.
>    In this case, it might be worthwhile attempting to map UUI data to an
>    appropriate SIP header field or to standardize a new header field.
>    However, the requirements and use cases for this are different enough
>    from those described in this document that these two situations
>    should be examined separately.  This document looks only at the
>    requirements and mechanisms for replicating the existing, widely used
>    and deployed ISDN UUI service.

This *still* troubles me!
Is the assumption here that *both* the UAC and UAS are gateways, so that 
this mechanism is solely for the tunneling of Q.931 and Q.763 UUI 
message over SIP?

I get the impression that an important use case is where at least *one* 
end (probably the UAS) is a SIP device. In that case it will already be 
*necessary* for it to understand and interpret UUI data. And where there 
is redundancy between SIP data and the UUI data, it will need to resolve 
the discrepancy.

Shouldn't that all be in scope here?

> 3.1.  Why INFO is Not Used
...
>    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

There are no call flows in the previous section. (They are now in 
another document.)

> 3.2.  MIME body Approach
> 
>    One method of transport is to transport the UUI information as a MIME
>    body.  This is in keeping with the SIP-T architecture [RFC3372] in
>    which MIME bodies are used to transport ISUP information.  Since the
>    INVITE will normally have an SDP message body, the resulting INVITE
>    with SDP and UUI will be multipart MIME.  This is not ideal as many
>    SIP UAs do not support multipart MIME INVITEs.

I don't understand this argument, since *no* SIP UAs currently support 
the UUI approach being proposed. The only entities that need to 
understand this are the UAC and the UAS. Both of them will have to 
support this UUI stuff for it to be used. If it were to be transported 
via Mime then that is what they would implement.

But the above is just nit picking, since I do agree with the problem of 
using mime bodies with REFER. I don't have any real problem with using a 
new header for this.

> 5.  Syntax for UUI Header Field
...
>        UUI         = "User-to-User" HCOLON uui-data *(SEMI uui-param)
>        uui-data    = token
>        uui-param   = enc-param | cont-param | purp-param | generic-param
>        enc-param   = "encoding=" ("hex" | token)
>        cont-param  = "content=" ("isdn-uui" | token)
>        purp-param  = "purpose=" ("isdn-interwork" | token)

At the very least, I would request that this be expanded a little bit 
for future flexibility, by permitting the uui-data to be either a token 
or a string. While the encoding you have chosen works as a token, other 
encodings may need the additional flexibility of a string.

        uui-data    = token | quoted-string

> 6.3.  Registration of SIP Option Tag

This section registers the new option tag. But I find almost nothing 
that defines the semantics of the option. (Section 5 does include the 
following:

>    A UA that supports this feature and the "uui" option tag MUST support
>    the call flows in [johnston-dispatch-sip-cc-uui]...

but that is pretty thin from a normative perspective.

Of particular note, does support for the option tag mean support for the 
particular encoding, content, and purpose included in this document? Or 
does it only mean support for the header and params in the abstract? 
(That wouldn't be very useful.)

I don't see how it can mean support for some other yet to be defined 
values for those. Yet if it only means support for the current ones, 
then how will one indicate support for future ones?

The only way out of this that I can see is to have separate options, 
either for particular values of each parameter, or for particular 
combinations of values of all the parameters.

So you might have options uui-purpose-isdn-interwork, uui-content-isdn, 
and uui-encoding-hex. Or you might just have option uui-isdn-interwork 
that means the combination.

I also am not finding much explanation of the semantics of the content 
and purpose parameters. I can only extrapolate from a single example of 
each, which I'm having trouble doing.

I'm guessing that 'content' must refer to the precise syntax of the 
contained data, after decoding. So presumably it must map onto some 
particular spec. For isdn-uui, would that be [Q931] or [Q763]? If so, 
shouldn't it refer to something specific in that document?

'purpose' is even less clear to me. Does it refer to why it is being 
included? Or what is to be done with it? If received by a UA that is not 
an ISDN gateway, how can it decide if this is something it should be 
trying to process? Is it still ISDN interworking if neither the UAC nor 
UAS is connected to an ISDN network?

Suppose I was developing a sophisticated UA that potentially might be 
usable by a call center operator. How should purpose=isdn-interwork 
affect the operation of this device?

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Fri, 03 Jul 2009 11:13:18 -0500

Paul,

Thanks for your comments.  See mine below.

Thanks,
Alan

Paul Kyzivat wrote:
> Hi Alan,
>
> I took a quick look at this doc and the requirements doc as well. I 
> have a few thoughts:
>
> From section 1:
>
> Is the assumption here that *both* the UAC and UAS are gateways, so 
> that this mechanism is solely for the tunneling of Q.931 and Q.763 UUI 
> message over SIP?
>
> I get the impression that an important use case is where at least 
> *one* end (probably the UAS) is a SIP device. In that case it will 
> already be *necessary* for it to understand and interpret UUI data. 
> And where there is redundancy between SIP data and the UUI data, it 
> will need to resolve the discrepancy.

Not quite.  We are not making the assumption that both are gateways, 
although that is possible.  Most likely, one element is SIP enabled.  
However, it is not a fully intelligent SIP endpoint - the basic software 
and application (probably many years old) is unchanged but a SIP 
interface (SIP trunk) has been added.  As such, the SIP stack does not 
know anything about the UUI as it is implementing exactly the ISDN UUI 
service - the information is just pushed up the stack to another 
application, and this application knows nothing about SIP.  It still 
thinks it is using an ISDN trunk.  So this mechanism allows us to easily 
and quickly get SIP into these applications without having to rewrite 
the entire application to make it SIP aware.  Does that make any sense?  
Honestly don't know how I can explain it more clearly than this.  And 
this is not some corner case or exception - this is a *huge* opportunity 
for SIP if we can get this mechanism standardized.

> Shouldn't that all be in scope here?

For the case I described above, where only SIP trunking is being used, 
the best you can do is indicate the purpose (the application using the 
UUI) is the ISDN UUE, and the content is how the ISDN spec defines it - 
an opaque blob of information.  The ISDN does not know if the UUI 
contains an account number, a name, etc - but the application making use 
of the SIP trunking does.

> There are no call flows in the previous section. (They are now in 

Yes, I missed this in splitting the documents.  I need to edit the text 
a little as well so they go together better but I ran out of time as 
I'll be out of the office all next week.

> the UUI approach being proposed. 

No, Avaya and at least one other vendor have implemented and deployed 
the User-to-User header field in customer networks.  As I said, there is 
a big demand for this, and the marketplace will not wait much longer for 
us to get this finalized.

But in our, and others, experience, adding support for a single new 
header field is easy.  Adding complete support for Multipart MIME is 
much harder and impacts many more things.

> The only entities that need to understand this are the UAC and the 
> UAS. Both of them will have to support this UUI stuff for it to be 
> used. If it were to be transported via Mime then that is what they 
> would implement.
>
> But the above is just nit picking, since I do agree with the problem 
> of using mime bodies with REFER. I don't have any real problem with 
> using a new header for this.

Excellent - I am very glad to hear this.

> for future flexibility, by permitting the uui-data to be either a 
> token or a string. While the encoding you have chosen works as a 
> token, other encodings may need the additional flexibility of a string.
>

OK, I guess I'm OK with that.  For the isdn-interwork purpose, we'll 
require the token, but other applications could utilize the quoted string.

> Of particular note, does support for the option tag mean support for 
> the particular encoding, content, and purpose included in this 
> document? Or does it only mean support for the header and params in 
> the abstract? (That wouldn't be very useful.)

Yes, this needs clarification.  I'd suggest we define the option tag to 
be uui-isdn which means it understands the header field and the 
isdn-interwork purpose, and the call flows, including escaping into 
redirection and Refer-To URIs.

> combinations of values of all the parameters.

New applications using this header field would have the option of 
defining a new SIP option tag which would mean support for the header 
field and their new purpose.

>
> So you might have options uui-purpose-isdn-interwork, 
> uui-content-isdn, and uui-encoding-hex. Or you might just have option 
> uui-isdn-interwork that means the combination.

I think the latter.  I see it as a hierarchy - the application or 
purpose is the top one.  Each purpose has a number of contents that it 
supports.  Each content has a number of encoding schemes it supports.

> and purpose parameters. I can only extrapolate from a single example 
> of each, which I'm having trouble doing.
>

Not really.  In this case, isdn-uui effectively means "opaque data" 
which is how ISDN defines the UUI - it is completely undefined, 
necessarily so  by the strict layering used in the ISDN application.

> included? Or what is to be done with it? If received by a UA that is 
> not an ISDN gateway, how can it decide if this is something it should 
> be trying to process? Is it still ISDN interworking if neither the UAC 
> nor UAS is connected to an ISDN network?

The purpose is the application using the UUI.  Others have expressed an 
interest in carrying other data in the header field, in which case a new 
purpose would be defined.  I'll see if I can think of an example one.

Basically, if two UAs both support the header but have different 
applications generating and consuming the UUI, it will not work.  This 
is not a SIP failure, and there is nothing SIP can do about it.  But 
this purpose header field allows the UAs to detect this condition.

> affect the operation of this device?

To make it work in today's contact center applications, supporting 
isdn-interwork would likely make it work in an application, provided the 
appropriate call center application also ran on it.  Some contact 
centers do not use ISDN UUI, instead they use all kinds of really, 
really ugly CTI protocols running in parallel.  This is a way of moving 
those to the ISDN model, and from there to a more intelligent endpoint 
SIP model.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Jul 2009 19:39:29 -0400

Hi Alan,

responses inline. I've trimmed out the parts that don't require more 
discussion.

	Thanks,
	Paul

Alan Johnston wrote:
> thinks it is using an ISDN trunk. 

Then in the way I meant the question, both ends *are* gateways.

But then if someone wishes to build native sip gear to plug into this 
environment, then it will still have to understand this isdn encoding. 
Perhaps that is the cruel truth, unless all the equipment is replaced at 
once.

> require the token, but other applications could utilize the quoted string.

I would hope that when the token encoding is sufficient, then either 
form would be accepted. Or it would perhaps be ok to specify for a 
particular encoding (hex) that the token encoding must be used. I don't 
see how the purpose has anything to do with it.

> redirection and Refer-To URIs.

I'd like to hear some other opinions on whether to have tag per param 
for tag, or a tag for the combination of param values. I think I'm ok 
with what you propose.

> supports.  Each content has a number of encoding schemes it supports.

I guess I'm ok with that, pending nailing down the definition of "purpose".

> necessarily so  by the strict layering used in the ISDN application.

I don't believe you!

If that is the case, then the UAC and UAS must have a private side 
agreement about what the isdn-uui content means. Is that really what you 
mean?

You already state that the first byte is a protocol discriminator. There 
must also be something, somewhere, that specifies the mapping from a 
particular value for that byte to a particular protocol/format. If there 
is, then that should be part of the definition of this content.

> purpose would be defined.  I'll see if I can think of an example one.

So are you saying that a particular call center application might 
constitute a distinct "purpose"?

> this purpose header field allows the UAs to detect this condition.

In that case, perhaps "isdn-interwork" isn't really a single purpose at 
all, unless any two pieces of equipment that support that purpose can 
then interwork without knowing any more about each other.

> really ugly CTI protocols running in parallel. 

Yes, I know! :-(

> This is a way of moving

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 26 Jul 2009 01:01:19 +0200

Just to respond to this bit of the message:

> > However, it is not a fully intelligent SIP endpoint - the basic 
> > software and application (probably many years old) is 
> unchanged but a 
> > SIP interface (SIP trunk) has been added.  As such, the SIP 
> stack does 
> > not know anything about the UUI as it is implementing 
> exactly the ISDN 
> > UUI service - the information is just pushed up the stack 
> to another 
> But then if someone wishes to build native sip gear to plug 
> into this environment, then it will still have to understand 
> this isdn encoding. 
> Perhaps that is the cruel truth, unless all the equipment is 
> replaced at once. 

I've said this before and I'll say it again. The bit being delivered to the end UE is not "isdn encoding". If it was ISDN encoding, then the ISDN / SIP gateway would be able to interpret it and map it into SIP. Rather it is some application sitting above the ISDN call control layer in the calling terminal, which is wishing to communicate with its peer application running in the destination SIP UA, or gateway.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Saturday, July 04, 2009 12:39 AM
> To: Alan Johnston
> Cc: [email-masked]
> Subject: Re: [dispatch] I-D 
> Action:draft-johnston-sipping-cc-uui-08.txt
> 
> Hi Alan,
> 
> responses inline. I've trimmed out the parts that don't 
> require more discussion.
> 
> 	Thanks,
> 	Paul
> 
> Alan Johnston wrote:
> > Paul,
> > 
> >> that this mechanism is solely for the tunneling of Q.931 and Q.763 
> >> UUI message over SIP?
> >>
> > However, it is not a fully intelligent SIP endpoint - the basic 
> > software and application (probably many years old) is 
> unchanged but a 
> > SIP interface (SIP trunk) has been added.  As such, the SIP 
> stack does 
> > not know anything about the UUI as it is implementing 
> exactly the ISDN 
> > UUI service - the information is just pushed up the stack 
> to another 
> But then if someone wishes to build native sip gear to plug 
> into this environment, then it will still have to understand 
> this isdn encoding. 
> Perhaps that is the cruel truth, unless all the equipment is 
> replaced at once.
> 
> I would hope that when the token encoding is sufficient, then 
> either form would be accepted. Or it would perhaps be ok to 
> specify for a particular encoding (hex) that the token 
> encoding must be used. I don't see how the purpose has 
> anything to do with it.
> 
> > Yes, this needs clarification.  I'd suggest we define the 
> option tag 
> > to be uui-isdn which means it understands the header field and the 
> I'd like to hear some other opinions on whether to have tag 
> per param for tag, or a tag for the combination of param 
> values. I think I'm ok with what you propose.
> 
> >> I also am not finding much explanation of the semantics of the 
> >> content and purpose parameters. I can only extrapolate 
> from a single 
> >> example of each, which I'm having trouble doing.
> >>
> If that is the case, then the UAC and UAS must have a private 
> side agreement about what the isdn-uui content means. Is that 
> really what you mean?
> 
> You already state that the first byte is a protocol 
> discriminator. There must also be something, somewhere, that 
> specifies the mapping from a particular value for that byte 
> to a particular protocol/format. If there is, then that 
> should be part of the definition of this content.
> 
> >> be trying to process? Is it still ISDN interworking if neither the 
> >> UAC nor UAS is connected to an ISDN network?
> > 
> > The purpose is the application using the UUI.  Others have 
> expressed 
> > an interest in carrying other data in the header field, in 
> which case 
> > a new purpose would be defined.  I'll see if I can think of 
> an example one.
> 
> So are you saying that a particular call center application 
> might constitute a distinct "purpose"?
> 
> In that case, perhaps "isdn-interwork" isn't really a single 
> purpose at all, unless any two pieces of equipment that 
> support that purpose can then interwork without knowing any 
> more about each other.
> 
> > isdn-interwork would likely make it work in an application, 
> provided 
> > the appropriate call center application also ran on it.  
> Some contact 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jul 2009 09:13:51 -0400

Keith,

If this is *not* ISDN encoding, then where is the indication of what 
encoding is being used? Are you saying that this is a private agreement 
between the UAC and UAS, neither signaled nor negotiated? How can that 
possibly work?

I thought the first byte of the value was a registered format indicator.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 27 Jul 2009 16:12:33 +0200

1st octet of the payload.

Keith 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, July 27, 2009 2:14 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> If this is *not* ISDN encoding, then where is the indication 
> of what encoding is being used? Are you saying that this is a 
> private agreement between the UAC and UAS, neither signaled 
> nor negotiated? How can that possibly work?
> 
> >> Perhaps that is the cruel truth, unless all the equipment 
> is replaced 
> >> at once.
> > 
> > I've said this before and I'll say it again. The bit being 
> delivered to the end UE is not "isdn encoding". If it was 
> ISDN encoding, then the ISDN / SIP gateway would be able to 
> interpret it and map it into SIP. Rather it is some 
> application sitting above the ISDN call control layer in the 
> calling terminal, which is wishing to communicate with its 
> peer application running in the destination SIP UA, or gateway.
> > 
> > regards
> > 
> > Keith
> > 
> require more 
> >> Perhaps that is the cruel truth, unless all the equipment 
> is replaced 
> >> at once.
> >>
> >> particular encoding (hex) that the token encoding must be used. I 
> >> don't see how the purpose has anything to do with it.
> >>
> >> agreement about what the isdn-uui content means. Is that 
> really what 
> >> you mean?
> >>
> >> You already state that the first byte is a protocol discriminator. 
> >> There must also be something, somewhere, that specifies 
> the mapping 
> >> from a particular value for that byte to a particular 
> >> protocol/format. If there is, then that should be part of the 
> >> definition of this content.
> >>
> >> In that case, perhaps "isdn-interwork" isn't really a 
> single purpose 
> >> at all, unless any two pieces of equipment that support 
> that purpose 
> >> can then interwork without knowing any more about each other.
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jul 2009 11:09:51 -0400

> 1st octet of the payload.

Fine. But what does the first octet of the payload *mean*?

Aren't the encodings corresponding to particular values of that octet 
defined somewhere? If so, how many of the 256 possible values are 
defined, and who controls how new values can be defined?

I'm pretty sure it isn't IETF or IANA.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Jul 2009 03:23:26 -0500

You could always read the appropriate ITU specs:
http://www.itu.int/rec/T-REC-Q.957.1-199607-I/en

and

http://www.itu.int/rec/T-REC-Q.931-199805-I/en
(section 4.5.30)

And then, there would be all the "national" values,
and, even more importantly, vendor specific values. Large operators
and equipment manufacturers often have their own specificatons
for use of UUS.

UUS is more more complicated than just sending a blob in an 
information element.

And as I said yesterday, there is more to it than just carrying the UUI IE
blob.

There is also Facility IE for example. The other thing is that UUS may be 
related to what specific ISDN message carries the information. I don't think 
this is addressed in the draft. So it may impose restrictions on when it 
is appropriate to use this draft, versus, for example, the alternative of 
tunnelling the whole ISDN messages (à-la RFC 3204).

I believe the intent of this draft is to cover ONLY the 
UUIE case, not the others (again, like Facility). Perhaps I'm wrong,
but at the very least, it needs to be clarified in the document.

Realistically, just defining the blob for carrying UUI will NOT allow
us to have any interoperability. It will just allow us to carry the blob.

Somebody else, perhaps other SDOs, or even just the vendors, would have
to define the interop procedures.

If it's something that is only meant to be vendor-specific, then I'm
not even sure we need any standardization. One can use one of the 
existing mechanisms in SIP (e.g., URI parameter, MIME bodies, proprietary
headers) to achieve this.

> Sent: Monday, July 27, 2009 08:10
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Aren't the encodings corresponding to particular values of 
> that octet defined somewhere? If so, how many of the 256 
> possible values are defined, and who controls how new values 
> can be defined?
> 
> >> encoding is being used? Are you saying that this is a private 
> >> agreement between the UAC and UAS, neither signaled nor 
> negotiated? 
> >> How can that possibly work?
> >>
> >> delivered to the end UE is not "isdn encoding". If it was ISDN 
> >> encoding, then the ISDN / SIP gateway would be able to 
> interpret it 
> >> and map it into SIP. Rather it is some application sitting 
> above the 
> >> ISDN call control layer in the calling terminal, which is 
> wishing to 
> >> communicate with its peer application running in the 
> destination SIP 
> >> UA, or gateway.
> >>> regards
> >>>
> >>> Keith
> >>>
> discriminator.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 28 Jul 2009 10:39:20 +0200

If people read ITU-T Recommendation Q.957.1 (which incidently is the correct reference that should appear in the charter proposal and not Q.931) the key works you are looking for are UUS service 1 implicit. This is "implicit" in that the service is requested merely by the presence of the data to be transferred and does not involve the use of the Facility information element to control this.

Q.957.1 the references Q.931 for the coding of the information elements required by the procedures in Q.957.1.

(The procedures in ITU-T Recommendation Q.931 defines two different usages:
-       the mapping of user data in X.29 into Q.931 packet data.
-       the user to user bearer service which essentially defines a call that consists of the control signalling only (plus encapsulated data in the signalling) and has no separate bearer path).

regards

Keith

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 9:23 AM
> To: Paul Kyzivat; DRAGE, Keith (Keith); Alan Johnston
> Cc: [email-masked]
> Subject: RE: [dispatch] I-D
> And then, there would be all the "national" values, and, even
> more importantly, vendor specific values. Large operators and
> equipment manufacturers often have their own specificatons
> for use of UUS.
>
> And as I said yesterday, there is more to it than just
> carrying the UUI IE blob.
>
> There is also Facility IE for example. The other thing is
> that UUS may be related to what specific ISDN message carries
> the information. I don't think this is addressed in the
> draft. So it may impose restrictions on when it is
> appropriate to use this draft, versus, for example, the
> alternative of tunnelling the whole ISDN messages (à-la RFC 3204).
>
> I believe the intent of this draft is to cover ONLY the UUIE
> case, not the others (again, like Facility). Perhaps I'm
> wrong, but at the very least, it needs to be clarified in the
> document.
>
> Realistically, just defining the blob for carrying UUI will
> NOT allow us to have any interoperability. It will just allow
> us to carry the blob.
>
> Somebody else, perhaps other SDOs, or even just the vendors,
> would have to define the interop procedures.
>
> If it's something that is only meant to be vendor-specific,
> then I'm not even sure we need any standardization. One can
> use one of the existing mechanisms in SIP (e.g., URI
> parameter, MIME bodies, proprietary
> > >>>> I guess I'm ok with that, pending nailing down the
> definition of
> > >>>> "purpose".
> > >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 09:03:57 -0400

> http://www.itu.int/rec/T-REC-Q.931-199805-I/en

How would I know those are the "appropriate" specs to read?
In the doc, Q.957 isn't mentioned at all. Q.931 is referenced as an 
informative document in the list of references, and referenced 
non-normatively in the first paragraph of the Overview.

There is no linkage at all of encoding/content/purpose params to either 
of these specs.

> and equipment manufacturers often have their own specificatons

So, how would the use of national and/or vendor specific values be 
indicated in this header?

> us to have any interoperability. It will just allow us to carry the blob.

That is a big part of my concern.

I am looking for the direct linkage from the values in the header to the 
specs that define what those values mean.

> to define the interop procedures.

That would be a problem.

> headers) to achieve this.

I agree.

	Thanks,
	Paul