Re: reRouteIndication

23 Sep 1997


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

Callaghan, Robert

tags (0)

participants (1)