September 1997 - sg16-avd - lists.packetizer.com

Re: reRouteIndication
by Joerg Ott 20 Sep '97

20 Sep '97

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

1 0

Re: REH.225.0 protocol identifier
by Joerg Ott 20 Sep '97

20 Sep '97

Gary, I suspect that this is the *only* save way to do so. Also with respect to version numbers: do not forget to update the "References" section in all documents to point to H.245 version 3 (indicating 1998)... Joerg ---------------------------------------------------------------------- Joerg Ott jo(a)tzi.org Universitaet Bremen, Germany voice +49 421 218-2085 TELES AG fax +49 421 218-7000 > > Glen, > > Will you be changing the protocolIdentifier value for version 2 to: > {itu-t (0) recommendation (0) h (8) 2250 version (0) 2} > > And is this the prefered method to detect the difference between a version > 1 and a version 2 terminal??? >

1 0

FW: Octet-aligned encoding for H.450.x ?
by Klaghofer, Karl PN M BT 19 Sep '97

19 Sep '97

Sorry, In the meantime I found the H.225 section telling about basic aligned variant of X.691 to be used for H.225.0 User-user information element ASN.1 encoding. The same of course shall apply for H.450 Supplementary service APDUs (which are carried in User-user information element) Regards, Karl Klaghofer Siemens AG ---------- From: Klaghofer, Karl PN M BT Sent: Thursday, September 18, 1997 6:15 PM To: 'itu-sg16List' Subject: Octet-aligned encoding for H.450.x ? Importance: High The H.450 Supplementary Services make use of the Packed Encoding Rules (PER) according to X.691 (inline with H.225, H.245). X.691 specifies four encoding rules: BASIC-PER, CANONICAL-PER, both in two variants the ALIGNED variant, and the UNALIGNED variant. Are all of these encodings mandatory in H.323 (H.225, H.245) to support ? Should we limit the X.691 variants in H.450.x (clause 9 of H.450.1) to ALIGNED only ? Regards, Karl Klaghofer Siemens AG karl.klaghofer(a)mch.pn.siemens.de

1 0

review copy of H.225.0 version 2 available
by Glen Freundlich 19 Sep '97

19 Sep '97

Fellow H.323ers, I have posted 2 H.225.0 V2 files to the incoming directory of the gctech ftp site for early review. h2250v2b.doc indicates the changes from the Sunriver meeting. h225bdif.doc shows the changes between H.225.0 version 1 and h2250v2b. Note that these documents are not in their desired final state, but I think they are close. I have posted these now to allow review to be sure that I have included material from Sunriver. Please let me know if you see any omissions or errors, or if you have any suggestions. I have a few issues to resolve yet, and I have received a few comments which I have not had a chance to incorporate. Please get your comments to me by the end of the day Wednesday, September 24, so that I can forward the final documents to the Rapporteur by September 25. Best Regards, Glen Freundlich (editor H.225.0) -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

TD-27 text for h.323
by gthom 19 Sep '97

19 Sep '97

Pete and others, I took some editorial liberty with the text of TD-27. It is contained below. I expect to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put it into 8.2. Any suggestions, changes, clarifications??? Thanks Gary ****************************************** "To allow gatekeepers to re-route connections from endpoints that do not support supplementary services, endpoints shall support the reception of empty capability sets (i.e. Terminal Capability sets that indicate that the endpoint sending the message has no receive capabilities). This feature also allows 'network' elements such as PBXs, call centers, and IVR systems to re-route connections independent of supplementary services and facilitates pre-connect announcements. It can also be used to delay H.245 media establishment when features such as Gatekeeper based user location is being used. It is also highly recommended that Version 1 endpoints support this feature. On reception of an empty capability set an endpoint shall enter a paused state. If media stream or data logical channels were previously opened by the endpoint, they should be closed. In this state an endpoint shall accept the opening of logical channels from the remote end based on the usual rules and continue to receive media from open logical channels from the remote end. This allows endpoints to receive announcements (e.g. pre-connect call progress) where the announcing entity does not wish to receive media from the endpoint. On reception of a non-empty capability set in this paused state an endpoint shall reset its H.245 state to that which it was in prior to entering the paused state. This allows an endpoint to be connected to a different endpoint when it is released from the paused state. Note that the non-empty capability set shall not be sent to an endpoint until all its transmit and receive logical channels have been closed. A switching entity should also send an H.450 redirection indication Facility message if the endpoint is being re-routed. The endpoint shall then proceed with normal H.245 connection establishment signalling. When leaving the paused state an endpoint shall take part in master/slave determination signalling, and may proceed with normal open logical channel signalling procedures. When an MC receives a release from the paused state it shall act as if a new endpoint has entered the conference. Unless its capabilities have changed, an endpoint need not resend a capability set as the gatekeeper will have supplied this to remove any paused state in the remote endpoint. This option of not sending a capability set enables faster reconnection. ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/19/97 Time: 11:47:19 -------------------------------------

1 0

Re: reRouteIndication
by Pete Cordell 19 Sep '97

19 Sep '97

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(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >Sent: 19 September 1997 10:40 >To: ITU-SG16(a)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(a)siemens.at >================================ >

1 0

New draft of H.245
by Mike Nilsson 19 Sep '97

19 Sep '97

Dear Colleagues, I have put the latest draft of H.245 (Version 3) at ftp://www.labs.bt.com/pub/H245/h245_010.zip I will be out of the office until 29 September, and will have to submit this to the ITU very soon after my return. Therefore please review this draft as soon as possible, and as thoroughly as possible, so that we can minimise the number of corrections that we may need to make in January. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Video Processing Unit Fax: +44 1473 643791 * * Centre for Human Communications E-mail: nilssome(a)boat.bt.com * * BT Laboratories [MLB3/16] * * Martlesham Heath * * Ipswich IP5 7RE * * UK * **********************************************************************

1 0

New draft of H.245
by Mike Nilsson 19 Sep '97

19 Sep '97

Dear Colleagues, I have put the latest draft of H.245 (Version 3) at ftp://www.labs.bt.com/pub/H245/h245_010.zip I will be out of the office until 29 September, and will have to submit this to the ITU very soon after my return. Therefore please review this draft as soon as possible, and as thoroughly as possible, so that we can minimise the number of corrections that we may need to make in January. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Video Processing Unit Fax: +44 1473 643791 * * Centre for Human Communications E-mail: nilssome(a)boat.bt.com * * BT Laboratories [MLB3/16] * * Martlesham Heath * * Ipswich IP5 7RE * * UK * **********************************************************************

1 0

H.332 white paper for review in the Incoming directory
by Vineet Kumar 19 Sep '97

19 Sep '97

Dear H.323 Colleagues, I have uploaded the H.332 white paper (h332.doc in word 6) to the Incoming directory of the gctech.co.jp ftp site. Please review and email your comments by September 24. I will forward this document to the tsb in Geneva by September 25. Thanks. vineet -------------------------------------------------------------------- Vineet Kumar email: vineet_kumar(a)ccm.jf.intel.com Intel Corporation, JF3-212 phone: +1 503 264-3439 2111 NE 25th Avenue fax: +1 503 264-3375 Hillsboro, OR 97124-5961 -------------------------------------------------------------------- Opinions expressed are not necessarily shared by Intel --------------------------------------------------------------------

1 0

Re: reRouteIndication
by Ernst Horvath 19 Sep '97

19 Sep '97

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(a)siemens.at ================================

1 0