Req: Clarification on fast setup
pete.cordell at BT-SYS.BT.CO.UK
Tue Sep 23 12:27:35 EDT 1997
Not to judge the merits of your argument, but I think that there is a
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
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.
Siemens Business Communication Systems
Email: Robert.Callaghan at Siemenscom.com
>From: Pete Cordell [SMTP:pete.cordell at BT-SYS.BT.CO.UK]
>Sent: Friday, September 19, 1997 1:17 PM
>To: ITU-SG16 at mailbag.jf.intel.com
>Subject: Re: reRouteIndication
>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
> nonStandardData NonStandardParameter OPTIONAL,
>h4501SupplementaryService SEQUENCE OF H4501SupplementaryService
>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,
>E-Mail: pete.cordell at bt-sys.bt.co.uk
>Tel: +44 1473 646436
>Fax: +44 1473 645499
>>From: Ernst Horvath[SMTP:Ernst.Horvath at SIEMENS.AT]
>>Sent: 19 September 1997 10:40
>>To: ITU-SG16 at mailbag.jf.intel.com
>>Subject: Re: reRouteIndication
>>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
>>The Notify message could be used for that purpose (as an alternative to
>>Facility), but again, its use is supplementary-service specific (and
>>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
>>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
>>> 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
>>APDU' and confine all new functionality plus coding to the
>>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.
>>Tel: +43 1 1707 45897
>>Fax: +43 1 1707 56992
>>Email: ernst.horvath at siemens.at
More information about the sg16-avd