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

["DRAGE, Keith (Keith)" <[e-mail]>]

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

> -----Original Message-----
> From: Francois Audet [mailto:[e-mail]]
> Sent: Tuesday, July 28, 2009 9:23 AM
> To: Paul Kyzivat; DRAGE, Keith (Keith); Alan Johnston
> Cc: [e-mail]
> Subject: RE: [dispatch] I-D
> Action:draft-johnston-sipping-cc-uui-08.txt
>
> 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.
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> > Sent: Monday, July 27, 2009 08:10
> > To: DRAGE, Keith (Keith)
> > Cc: [e-mail]
> > Subject: Re: [dispatch] I-D
> > Action:draft-johnston-sipping-cc-uui-08.txt
> >
> >
> >
> > DRAGE, Keith (Keith) wrote:
> > > 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
> >
> > > Keith
> > >
> > >> -----Original Message-----
> > >> From: Paul Kyzivat [mailto:[e-mail]]
> > >> Sent: Monday, July 27, 2009 2:14 PM
> > >> To: DRAGE, Keith (Keith)
> > >> Cc: [e-mail]
> > >> Subject: Re: [dispatch] I-D
> > >> Action:draft-johnston-sipping-cc-uui-08.txt
> > >>
> > >> 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
> > >>
> > >> DRAGE, Keith (Keith) wrote:
> > >>> Just to respond to this bit of the message:
> > >>>
> > >>>>> 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.
> > >>>> 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.
> > >>> 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: [e-mail]
> > >>>> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> > >>>> Sent: Saturday, July 04, 2009 12:39 AM
> > >>>> To: Alan Johnston
> > >>>> Cc: [e-mail]
> > >>>> 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,
> > >>>>>
> > >>>>> 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:
> > >>>>>>
> > >>>>>>>    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.
> > >>>>> 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.
> > >>>> 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.
> > >>>>
> > >>>>>>> 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
> > >>>>> 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.
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>>>>> 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.)
> > >>>>> 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.
> > >>>> 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 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.
> > >>>>> 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.
> > >>>>
> > >>>> I guess I'm ok with that, pending nailing down the
> definition of
> > >>>> "purpose".
> > >>>>
> > >>>>>> 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?
> > >>>>> 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.
> > >>>> 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' 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?
> > >>>>> 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"?
> > >>>>
> > >>>>> 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.
> > >>>> 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.
> > >>>>
> > >>>>>> 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?
> > >>>>> 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.
> > >>>> Yes, I know! :-(
> > >>>>
> > >>>>> This is a way of moving
> > >>>>> those to the ISDN model, and from there to a more
> > >>>> intelligent endpoint
> > >>>>> SIP model.
> > >>>>>
> > >>>>>>     Thanks,
> > >>>>>>     Paul
> > >>>> _______________________________________________
> > >>>> dispatch mailing list
> > >>>> [e-mail]
> > >>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>