- sg16-avd - lists.packetizer.com

New draft of H.245
by Sakae Okubo 21 Sep '97

21 Sep '97

Dear SG16 colleagues, Mr. Nilsson's latest draft of H.245 (Version 3) h245_010.zip has been placed at the GCL ftp site. ftp://itu-t:sg15!avc@ftp.gctech.co.jp/Incoming/h245_010.zip Please note TDs of the Sunriver meeting have been moved to /9709_Sun directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 … [View More]

1 0

Re: reRouteIndication
by Scott Petrack 20 Sep '97

20 Sep '97

*If* there are some new fields in the h323-message-body structure, like "dummy" (or "empty") and "Notify". then I would ask the following: 1. The Notify structure be called "Notify-UUIE" (like all the other elements). The definition of this UUIE is of course whatever is agreed upon. I guess that the "empty" structure can stay NULL. (Even this group wouldn't define an "empty-UUIE" with just three dots ;-).) 2. Both the Notify and the dummy/empty UUIE should be added to the UUIEsRequested … [View More]structure of TD-28a. All of the then-present UUIEs were listed there; obviously these are part of the same story. I am not taking any stand on Pete's stuff. I just want to say if ...., then ..... (trying to harmonize things). Thanks, Scott pete.cordell(a)BT-SYS.BT.CO.UK on 09/19/97 08:17:12 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 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 >================================ > [View Less]

1 0

H.450.x ASN.1 Modules
by Markku Korpi 20 Sep '97

20 Sep '97

Pete,Glen,Dave & others For your convinience I have attached a file with the ASN.1 modules, that we used for verification of the H.450.x ASN.1 syntax. But Note: There is one remaining error on line 142 in a module copied from original X.880. For some reason the ASN.1 compiler complains that the "opcode" is not defined, even though the same construct does not have an error on line 109. In order to get the H.450 ASN.1 code to compile we commented this reference temporarily. In order to test … [View More]

1 0

ITU-T H.450.1, H.450.2 and H.450.3 Drafts for white papers
by Markku Korpi 20 Sep '97

20 Sep '97

Dear all, attached are the final drafts for issuing the white papers for the ITU-T recommendations H.450.1, H.450.2 and H.450.3. Please provide your final comments ASAP on tuesday at latest so that I can release the white papers on wednesday 24 Sept 97. Markku Korpi Editor of H.450.x SIEMENS Munich

1 0

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. … [View More]

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 … [View More]

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: … [View More]

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 … [View More]

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 … [View More]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 ------------------------------------- [View Less]

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 … [View More]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 >================================ > [View Less]

1 0