reRouteIndication

Joerg Ott jo at CS.TU-BERLIN.DE
Mon Sep 22 13:40:02 EDT 1997


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



More information about the sg16-avd mailing list