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@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@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
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@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@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
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@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@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@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
participants (3)
-
Glen Freundlich -
Joerg Ott -
Pete Cordell