*If* there are some new fields in the h323-message-body structure, like
"dummy" (or "empty") and "Notify". then I would ask the following:
1. The Notify structure be called "Notify-UUIE" (like all the other
elements). The definition of this UUIE is of course whatever is agreed
upon. I guess that the "empty" structure can stay NULL. (Even this group
wouldn't define an "empty-UUIE" with just three dots ;-).)
2. Both the Notify and the dummy/empty UUIE should be added to the
UUIEsRequested structure of TD-28a. All of the then-present UUIEs were
listed there; obviously these are part of the same story.
I am not taking any stand on Pete's stuff. I just want to say if ...., then
..... (trying to harmonize things).
Thanks,
Scott
pete.cordell(a)BT-SYS.BT.CO.UK on 09/19/97 08:17:12 PM
Please respond to ITU-SG16(a)mailbag.jf.intel.com
To: ITU-SG16(a)mailbag.jf.intel.com
cc: (bcc: Scott Petrack)
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
>================================
>
