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@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================