Cleaning up H.225 syntax

[Pete Cordell]

Dear All,

As most of you are aware, H.225/Q.931 is a strange hybrid combination of
Q.931 tag-length-value coding and ASN.1.  While this seemed sensible at
the time, it would seem that this could easily be cleaned up, leading to
a clearer standard, an easier implementation and one that would be
easier to use in large installations.  To this end it is suggested that
steps should be taken to remove this schizophrenia over future product
releases.  This involves first making entities tolerant of encoding
messages that are more ASN.1 based, and later swapping over to being
(almost) entirely ASN.1 based.  Many of the changes required are
consistent with making a robust product in a world where this split
personality operates.  With the pace of development in this area these
changes should not take long to flush out.

For example:

H.225 states that the Bearer Capability field shall be used, but in
practice it serves no purpose.  We could say:

Current implementations should insert a BC field when sending a SETUP
message, but should ignore it on reception.  It is intended that in
future endpoints will not need to send the BC field.

Also:

Currently the first E.164 number should be placed in the called party
number part when sending Q.931 messages.  Endpoints should be tolerant
of the first E.164 number being presented in either the Q.931 called
party number field, or the first member of the destinationAddress field
in the Setup-UUIE.  It is intended that in future only the
destinationAddress field in the Setup-UUIE will be used.

Currently the Facility based re-direction scheme is signalled by
including a zero length Facility IE and including the appropriate
information in the Facility-UUIE.  Receiving entities should be able
detect the invocation of the facility re-direction procedures by
detecting the presence of the Facility-UUIE without relying on the
presence of the zero length Facility IE.  It is intended that in future
the zero length facility IE shall not be used.

Currently Cause values can be presented in both the Q.931 Cause field
and H.225 ReleaseCompleteReason.  Cause values should only be sent in
the H.225 ReleaseCompleteReason, although receiving entities should
analyze both on reception.  In future it is intended that only the H.225
ReleaseCompleteReason field shall be used.

The only fields that we then use in Q.931 are Call State (used only in
STATUS), Date/Time (doesn't seem important), Display (nice but not
essential - could easily be added to H.225 v3), Notification and
Progress Indicators, and Signal.  Except for call State (which has a
fairly localized use) these are not critical to the operation of the
protocol and probably wouldn't be missed if you only wanted to deal with
the ASN.1!

If others have any thoughts on this matter I would be pleased to here
from them.

Regards,

Pete


=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================