Ernst, Glen,

I was working on a TD in Sunriver to suggest that Notify should be used, but I was advised that this was not the right message. It may be that Notify is the closest message to what is required and so I have no objections to it being used.

Glen has also suggested that additional fields such as reRouteReason, endpointAlias, originalDestination, and reRouteCounter should be added. The first two I agree with. The second one I'm not sure of what it means so don't know whether I agree with it or not. On reRouteCounter, I'm not sure what it would be counting. For the Facility-UUIE based re-route this is used so that the endpoint can check for infinite loops. As this would be used as a notify that a re-route had already been done, then the usefulness of this information is limited.

As to whether we include an indication of this sort, I am very wary of feature creep also. However, to me this seems such a fundamental call control feature that it shouldn't require supplementary service support. It should also be emphasized that this is not a replacement for anything in H.450.2, and ctComplete should be used when H.450.2 is in use. It is also light weight to implement; endpoints would not have to process it on reception, and re-routers should generate it, but it shouldn't be mandatory for them to generate it (for reasons such a anonymity in security and things like that).

Given these suggestions, a revised PDU might be:

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, notify CHOICE { reRouteIndication ReRouteIndication, ... } }, nonStandardData NonStandardParameter OPTIONAL, ..., h4501SupplementaryService SEQUENCE OF H4501SupplementaryService OPTIONAL }

ReRouteIndication ::= SEQUENCE { -- display no longer needed as this is in Notify message reRouteReason CHOICE { h4502Proxy NULL, thirdPartyService NULL, secondaryDialling NULL, qSIGInterworking NULL, ... } endpointAlias SEQUENCE OF AliasAddress, endpointInfo EndpointType, ... }

Pete

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

---

From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] Sent: 19 September 1997 10:40 To: ITU-SG16@mailbag.jf.intel.com Subject: Re: reRouteIndication

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 ================================