I think I understand, thanks for the clarification. (Of course maybe the
next sentence will prove that I don't understand ;-)):
I did not want to change anything about either the dummy/empty issue nor
the *content* of the
reRouteIndication issue. I was just saying that
IF
{there are possibilities for the h323-message-body that don't appear
in the UUIEs-requested structure in TD-28a}
then
{these new types should be added to the UUIEs-requested structure
mentioned in TD-28a}
We agreed to allow a GK to monitor what an endpoint does in this way, and I
just wanted it to be complete. Please let me know if this doesn't make
sense (and I didn't understand).
Scott
pete.cordell(a)BT-SYS.BT.CO.UK on 09/22/97 12:56:49 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
Joerg, Scott,
To clarify, dummy is a Hertzliya addition and nothing to do with
reRouteIndication. It's needed because if you send a supplementary
service message in a FACILITY you may not want to invoke the
Facility-UUIE. The optimum case would be to make the UUIE
h323-body-message part OPTIONAL, but this is not possible at this stage.
Hence adding the dummy field. As to the name.... dummy, empty,
emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm
sure we have bigger sins than this!). As for text to describe the
field, maybe...
empty - This option is used when a FACILITY message is sent, but the
Facility-UUIE is not to be invoked. This may occur when transporting
supplementary service messages.
reRouteIndication is a different issue. As re-routing can take place
independent of supp services, it seems reasonable that an endpoint
should be able to get notification of this event independent of supp
services.
Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell(a)bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================
>----------
>From: Joerg Ott[SMTP:jo@TZI.ORG]
>Sent: 20 September 1997 08:54
>To: ITU-SG16(a)mailbag.jf.intel.com
>Subject: Re: reRouteIndication
>
>Pete and all,
>
>two comments on this 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. 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. 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,
>
>First:
>
>I must have missed the "dummy" parameter before. I assume the need for
>an empty parameter comes from supplementary services, and I suggest to
>call
>it "empty NULL" (this is not an implementation but a standard after
>all)
>and to describe it somewhere in H.225.0. Searching through the
>document,
>the ASN.1 was the only place where "dummy" was used.
>(Should I be saying something about puzzles right now? :-)
>> 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.
>>
>
>Second:
>
>Overall, I agree with the mail from Ernst Horvath on this issue: we
>should
>not add such functionality to H.225.0, not even to version two.
>
>Joerg
>
