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(a)siemens.at
================================
