reRouteIndication

Callaghan, Robert Robert.Callaghan at SIEMENSCOM.COM
Tue Sep 23 09:49:53 EDT 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 at Siemenscom.com
Tel:    +1.561.997.3756

>-----Original Message-----
>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
>
>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