[Federico.Tosco at CSELT.IT: SG 16 future meetings]
Sakae Okubo
okubo at GCTECH.CO.JP
Tue Sep 23 11:53:06 EDT 1997
Joerg,
I considered changing "dummy" to "?", but didn't think the ASN.1
compiler would like that (just joking :)). Seriously, I'll try to think
of a better name and add some brief text describing its use in H.225.0.
Thanks for the pointer.
Regards,
Glen
Joerg Ott wrote:
>
> Pete, Scott,
>
> there must be some misuinderstanding going on: all I asked for was
> to call the structure component "empty" rather than "dummy" since it
> is used when the UUIE part is empty and its name should make this clear
> as should some brief description in H.225.0 (which I could not find in
> the document). Sorry for the confusion.
>
> What does the editor think about this, Glen?
>
> Joerg
> >
> > 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 at bt-sys.bt.co.uk
> > Tel: +44 1473 646436
> > Fax: +44 1473 645499
> > =================================
> >
> >
> > >----------
> > >From: Joerg Ott[SMTP:jo at TZI.ORG]
> > >Sent: 20 September 1997 08:54
> > >To: ITU-SG16 at 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
> > >
> >
>
> Gruesse,
> Joerg
--
Glen Freundlich ggf at lucent.com
Lucent Technologies office: +1 303 538 2899
11900 N. Pecos fax: +1 303 538 3907
Westminster, Colorado 80234 USA
More information about the sg16-avd
mailing list