Pete,
Not to judge the merits of your argument, but I think that there is a
procedure problem.
H.245, H.225.0, and the H.450.x series of specification were closed
based on the input from Sun River. I consider the introduction of new
feature requirement at this time is not acceptable. Major additions
without a public hearing is not acceptable. This mail exploder does not
constitute a public hearing. These proposals should be for the next
version.
Yes, minor editorial changes can be made in the January Geneva meeting.
What you are proposing involves a major philosophical question, the
level of support for features outside of H.450.
Bob
--------------------------------------
Robert Callaghan
Siemens Business Communication Systems
Email: Robert.Callaghan(a)Siemenscom.com
Tel: +1.561.997.3756
>-----Original Message-----
>From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK]
>Sent: Friday, September 19, 1997 1:17 PM
>To: ITU-SG16(a)mailbag.jf.intel.com
>Subject: Re: reRouteIndication
>
>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(a)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(a)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(a)siemens.at
>>================================
>>
