October 2000 - sg16-avd - lists.packetizer.com

AW: ASN.1 question on supporting Redirecting Number in Annex G
by Horvath Ernst 25 Oct '00

25 Oct '00

Mr. Michaely, the transport of information elements in their SCN encoded form is also foreseen in H.450 protocols. For this purpose H.450.1 defines the "generic" type H225InformationElement, which is a simple OCTET STRING. Within the octet string, any number of concatenated information elements can be embedded. The idea is that the whole string can be handed over unchanged to the Q.931 parsing process. Ernst Horvath > -----Ursprüngliche Nachricht----- > Von: Logan Modahala [mailto:lmodahal@cisco.com] > Gesendet am: Dienstag, 24. Oktober 2000 22:15 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: ASN.1 question on supporting Redirecting Number > in Annex G > > Mr. Michaely: > > We can define something like this: > > ieInfo IEInfoType OPTIONAL > > IEInfoType ::= SEQUENCE > { > ieID INTEGER (1..255), > ieContent OCTET STRING > ..... > } > > > ieID will identify ProgIndIE, RedirectIE and so forth based > on the IE Id assigned > in PSTN world. > ieContent is the actual encoding of the IE as per the Q.931 spec. > > - Logan > > > > Boaz Michaely wrote: > > > All, > > > > Following up the work started at Lovely Portland, we are > investigating the > > required additions to the AccessRequest et. al. messages of > H.225.0 Annex G. > > I will post a seperate note on that, but along the way, an > interesting question > > poped: > > > > The scenario: A VoIP network that is trying to terminate a > call in PSTN, over > > ISDN. The response from the CO indicates the call diversion > and includes the > > redirecting number element (which also indicates the > diversion reason) > > With H.225.0 v4 addition (TD-45 Osaka), this information > can be naturaly > > translated into H.225.0 setup message, while before that > the only way to convey > > the information was to translate it into H.450.3 > > Now, the network GK wishes to forward the call to the > Service Zone for call > > completion. In order to provide this information over > AccessRequest, we may add > > both H.450 element as well as RedirectingNumber element > (for the questionable > > sake of not mandating H.450 structures to do so). > > > > Now to my question: > > Assuming that indeed there is objection to mandate H.450 > structure for this > > purpose, how does one describe the RedirectingNumber IE > within the ASN.1 > > structure of H.225.0 Annex G ? > > After all, RedirectingNumber is imported from Q.931, and as > such is bitwise > > encoded. (there is probably a proper term for that which, > in my ignorance, I > > am unaware off - sorry). > > I have not seen any similar case, so the only solution I > came up with is to > > embed it in a BIT STRING. Is this realy how it should be > done ? If so, what > > would the exact syntax be ? > > > > Thanks, > > > > Boaz Michaely > > Senior System Architect, Corporate > > Comverse Network Systems > > Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44 > > mailto:boaz.michaely@ties.itu.int > > http://people.itu.int/~michaely > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Video experts: Proposal to add video to Desired/SupportedProtocols
by Boaz Michaely 25 Oct '00

25 Oct '00

Hi all, I would like some feedback from the video experts for a contribution I wish to make to expand SupportedProtocols, which has recently been added for use in ARQ, LRQ, SETUP, and Annex G Access Request messages. (ref: D-347 of 0200_Gen) "desiredProtocols - Identifies the type of protocols, in order of preference, the originating endpoint desires for its call (e.g., voice or fax). A resolving entity may use this field to locate an endpoint that also supports the protocol, giving consideration to the order of preference." Correct me if I'm wrong, but it seems that the objective of this addition, as documented in D-347 is not fully achieved, since video capabilities cannot be expressed. (it also strikes me that *protocols* may not be the best description of the capabilities being negotiated here.) If we were to complete the proposal, the change would probably look as below. My specific question to the video experts: What should the VideoCaps structure contain and how would it be used (clearly we do not intend to replace H.245 here). Thus, is there any good reason to conform to the structure of VoiceCaps - including the location of the '...' and the inclusion of 'SupportedPrefixes' ? (is it ever used ?) SupportedProtocols ::= CHOICE { nonStandardData NonStandardParameter, h310 H310Caps, h320 H320Caps, h321 H321Caps, h322 H322Caps, h323 H323Caps, h324 H324Caps, voice VoiceCaps, t120-only T120OnlyCaps, ..., nonStandardProtocol NonStandardProtocol, t38FaxAnnexbOnly T38FaxAnnexbOnlyCaps ---BEGIN , video VideoCaps ---END } VoiceCaps ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, ..., dataRatesSupported SEQUENCE OF DataRate OPTIONAL, supportedPrefixes SEQUENCE OF SupportedPrefix } ---BEGIN VideoCaps ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, ..., dataRatesSupported SEQUENCE OF DataRate OPTIONAL, supportedPrefixes SEQUENCE OF SupportedPrefix } ---END Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44 mailto:boaz.michaely@ties.itu.int http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: APC numbers for Geneva
by Sakae OKUBO 25 Oct '00

25 Oct '00

Dear Mr. Fortinsky, Mr. Audet, Mr. Luthi, In response to your requests, the following APC numbers have been allocated to your contributions: APC-1984 Editor (M Fortinsky) H.225.0 Annex G version 2 APC-1985 VocalTec Communications H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Clarifications Related to H.225.0 Annex G Service ID's APC-1987 Editor (F Audet) H.323 Annex M.1 - QSIG tunnelling APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ASN.1 question on supporting Redirecting Number in Annex G
by Boaz Michaely 24 Oct '00

24 Oct '00

All, Following up the work started at Lovely Portland, we are investigating the required additions to the AccessRequest et. al. messages of H.225.0 Annex G. I will post a seperate note on that, but along the way, an interesting question poped: The scenario: A VoIP network that is trying to terminate a call in PSTN, over ISDN. The response from the CO indicates the call diversion and includes the redirecting number element (which also indicates the diversion reason) With H.225.0 v4 addition (TD-45 Osaka), this information can be naturaly translated into H.225.0 setup message, while before that the only way to convey the information was to translate it into H.450.3 Now, the network GK wishes to forward the call to the Service Zone for call completion. In order to provide this information over AccessRequest, we may add both H.450 element as well as RedirectingNumber element (for the questionable sake of not mandating H.450 structures to do so). Now to my question: Assuming that indeed there is objection to mandate H.450 structure for this purpose, how does one describe the RedirectingNumber IE within the ASN.1 structure of H.225.0 Annex G ? After all, RedirectingNumber is imported from Q.931, and as such is bitwise encoded. (there is probably a proper term for that which, in my ignorance, I am unaware off - sorry). I have not seen any similar case, so the only solution I came up with is to embed it in a BIT STRING. Is this realy how it should be done ? If so, what would the exact syntax be ? Thanks, Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44 mailto:boaz.michaely@ties.itu.int http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: APC number request for Nov Rapp Meeting
by Sakae OKUBO 24 Oct '00

24 Oct '00

1 0

List of registered documents for the 9-10 November meeting
by Sakae OKUBO 24 Oct '00

24 Oct '00

1 0

Re: APC numbers for November meeting
by Sakae OKUBO 24 Oct '00

24 Oct '00

Dear Mr. Callaghan and Mr. Roy, In response to your requests, the following APC numbers have been allocated to your contributions: APC-1974 Editor (R Callaghan) H.450.12 - Common Information Additional Network Feature for H.323 APC-1975 Editor (R Callaghan) H.323 Annex M.3 - Tunneling DSS1 in H.323 APC-1976 Siemens H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture APC-1977 Siemens Deficiencies of H.225.0 for a native transport of DSS1 APC-1978 AT&T Mobility Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1979 AT&T Application Layer QOS Signalling Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1980 AT&T Common Value Added Intelligent Backend Services (BES) Protocols for all Applications Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] Reservation of MD-107 and MD-108 & upload o f MD -100
by Roy, Radhika R, ALCOO 23 Oct '00

23 Oct '00

Hi, Jaakko: Let us keep one thing in mind that 3GPP cases are only a part of the overall H.323 mobility. That is, high-speed mobile wireless environments like wireless LANs, indoor Pico- and micro-cells, and others are NOT covered by 3GPP architectures. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, October 19, 2000 4:14 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Reservation of MD-107 and MD-108 & upload of MD -100 Hi all, I reserve the MD-numbers: MD-107 and MD-108 for myself. The contributions are: MD-107 "3Gfication of H.323 Annex H Terms and Definitions" MD-108 "Comparison of 3GPP R'00 (v4) and H.323 Annex H Architectures". I will upload these contributions to the server probably next week. I will also upload MD-100 "List of MDs", containing the list of currently reserved MD-numbers to the Mobility-AHG folder in the incoming directory of the pictel ftp-site. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: test conditions provided
by Baese Gero 23 Oct '00

23 Oct '00

Dear experts and Mr. Li, thank you for your suggestions to further improve the testing conditions. > (1) Video codec > Profile 3 - H.263v2 Interactive and Streaming Wireless Profile > Profile 4 - H.263v3 Interactive and Streaming Wireless Profile It makes a lot of sense to incorporate both of the wireless profiles. There is no problem to remove Annex O from the list as well. > (2) Lower layer testing condition If you read the test conditions carefully you will see we nowhere propose to implement the whole protocol stack. Instead we are using a model with two parameters to keep it uncomplex but realistic. These two parameters are the loss rate of the radio frame and the length of it. Acting on our suggestion makes it easy to generate comparable results quickly. Furthermore, the situation is not as simple as you depicted it. It is not sufficient to only use the frame loss rate p because there is a strong dependency on the length as well. Therefore we proposed the described model. Again, everybody interested in this work is requested to contribute with questions, comments and suggestions. Best Wishes Gero Baese ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H248 Implementors' Guide Draft v3
by Christian Groves 23 Oct '00

23 Oct '00

G'Day all, Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000. If anything is missed or erroneous please let me (and the list) know. The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available. My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval. Cheers, Christian PS: Please forgive me sending a 98k file to the list but the Pictel server has been down.

2 3