reRouteIndication

Scott Petrack Scott_Petrack at VOCALTEC.COM
Sat Sep 20 20:41:30 EDT 1997


*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 at BT-SYS.BT.CO.UK on 09/19/97 08:17:12 PM

Please respond to ITU-SG16 at mailbag.jf.intel.com

To:   ITU-SG16 at 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 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
>
>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 at siemens.at
>================================
>



More information about the sg16-avd mailing list