Dear Pete,
some observations on your mail:
It has been mentioned that when a gatekeeper performs a re-route it would be good for the client to know about it. After much investigation, there seems to be no message in Q.931 that handles this case.
The Notify message could be used for that purpose (as an alternative to Facility), but again, its use is supplementary-service specific (and was removed from H.450.1). In QSIG we use Facility whenever the information is to be processed by the endpoint, which is nearly always the case. Notify is restricted to situations where (less important) information is passed to the user without acting on it, and loss of the information would not be of great concern for the overall working of a feature.
In the text that I proposed in Sunriver I suggested that a Facility message with a H.450 ctComplete should be sent. However, this is not much use to an entity that does not support supplementary services.
The same situation can arise in the ISDN and QSIG case. But that does not prevent the re-routing from taking place, it only means that this terminal cannot display the information.
Therefore it might be useful to add can extra case to the H323-UU-PDU to cover this, e.g.:
H323-UU-PDU ::= SEQUENCE { h323-message-body CHOICE { setup Setup-UUIE, callProceeding CallProceeding-UUIE, connect Connect-UUIE, alerting Alerting-UUIE, userInformation UI-UUIE, releaseComplete ReleaseComplete-UUIE, facility Facility-UUIE, ..., progress Progress-UUIE, dummy NULL, reRouteIndication ReRouteIndication }, nonStandardData NonStandardParameter OPTIONAL, ..., h4501SupplementaryService SEQUENCE OF H4501SupplementaryService
OPTIONAL
}
ReRouteIndication ::= SEQUENCE { display IA5String (SIZE( 0..255) ), endpointInfo EndpointType, ... }
This could then be sent by a gatekeeper when a re-route has been done.
Your proposal does not say which message you would use. If it is Facility, then the Facility-UUIE could be enhanced instead.
However, I have a more general concern with this new proposal: An endpoint would still have to be upgraded to understand this coding. The only advantage compared to your original proposal (i.e. using an operation) might be slightly less complex coding. However, it goes against the intention of H.450.x. The idea behind the approach in H.450 is *not* to add new coding in H.225.0 whenever new functionality is created, but to use the *generic* container 'H4501 Supplementary Service APDU' and confine all new functionality plus coding to the supplementary service recommendation. This allows a neat modular approach where you tailor your system by choosing the right building blocks. Therefore I prefer using operations wherever possible.
Kind Regards, Ernst ================================ Ernst Horvath Siemens AG Tel: +43 1 1707 45897 Fax: +43 1 1707 56992 Email: ernst.horvath@siemens.at ================================