August 1999 - sg16-avd - lists.packetizer.com

H283 decided document is available
by Mark Duckworth 25 Sep '99

25 Sep '99

I uploaded it to the ftp site. ftp://standard.pictel.com/avc-site/Incoming/H283_decided.zip Mark

2 1

H.323v4 draft
by Paul E. Jones 09 Sep '99

09 Sep '99

Dear Experts, I have posted a preliminary draft of H.323v4 in the Incoming directory of the AVC site. This draft should contain all of the text approved for v4 during the Berlin meeting. As was mentioned Berlin, we would like to work out issues with the gateway decomposition and application sections as much as possible BEFORE the October meeting. Please, make comments. Also, there was some text that was accepted in Berlin for the Implementers Guide (relating to v2 and v3) and other text that was intended to be introduced as a rapporteur's TD during the September meeting to correct errors in the H.323v3 white contribution. All of that text should be in this v4 draft document. Please bring my attention to anything that is missing. I'll have to speak with Mr. Skran to find out exactly what he would like to introduce via a Rapporteur's TD for H.323v3. However, below is a list of things I would personally like to see introduced during the September meeting. o All changes made to Annex C, which were made to preserve backward compatibility. o Changes made to section 8.1.7 (fast connect procedure) o Changes to 8.4.6 (third party pause) Please voice your opinion on additions to or deletions from this list. Best Regards, Paul

3 3

Re: H.450.3 supplementary service Interrogation
by Korpi, Markku 31 Aug '99

31 Aug '99

Vivek , The interrogation construct came unchanged from ISO Qsig to H.450.3. The range "0..29" in IntResultList ::= SET SIZE (0..29) OF IntResult allows interrogating of 30 services. The range certainly should not be "0..2". An instance of IntResult can arise for every basic service (when interrogating for all basic services) and for every diversion type (3). There are 9 basic services defined in the ECMA and ISO standards, so this would seem to give a theoretical limit of 27. The max index of 29 therefore does no harm. It would need increasing if the number of basic services were to be increased. Regards Markku -------------------- Markku Korpi Siemens Information & Communication Networks 4900 Old Ironsides Dr., Santa Clara, CA95052, U.S.A. Tel. +1 408 492 7328, Mobile +1 408 390 5677, Fax. +1 408 492 4666 Email: markku.korpi(a)icn.siemens.com > -----Original Message----- > From: vjaiswal(a)hss.hns.com [mailto:vjaiswal@hss.hns.com] > Sent: Friday, August 27, 1999 2:57 AM > To: vineet.kumar(a)intel.com; Markku.korpi(a)icn.siemens.de > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.450.3 supplementary service > > > > > Hi vineet, > In H.450.3, call forwarding supplementary services, the response to > interrogateDiversionQ.Invoke APDU is defined as follows > > IntResultList ::= SET SIZE (0..29) OF IntResult > IntResult ::= SEQUENCE > { servedUserNr EndpointAddress, > basicService BasicService, > procedure Procedure, > divertedToAddress EndpointAddress, > remoteEnabled BOOLEAN DEFAULT FALSE, > extension CHOICE > {extensionSeq ExtensionSeq, > nonStandardData NonStandardParameter } > OPTIONAL, > > > ? > > } > > > > I would like to know, why the result has been kept a list of maximum 29 > nodes. > As far as my understanding goes, a list of 3 nodes would suffice, one > node > for > each service type (CFU/CFB/CFNR). > > > > Ane help would be appreciated. > > Thanks > > Regards > > Vivek Jaiswal > > Hughes Software Systems

1 0

H.323 versions
by Michaela Goffri 31 Aug '99

31 Aug '99

Hi Everyone, 1. Are there any documents that summarize the differences between the different versions (1-4) of the H.323 standard? 2. What is the latest version for H.225.0 (I have a document from 2/98 that I downloaded from ITU-T - I am not sure its the latest). Thanks, Michaela

2 1

Re: ASN.1 Syntax of H.245
by Pete Cordell 31 Aug '99

31 Aug '99

Mike, I agree that this change has to be made. The original form makes no sense and, once pointed out, is clearly defective. As you say, it will NOT affect the bits on the wire. Indeed, depending on the compiler you have, you can almost get away without changing any code you have written (although re-compiling and tweaking would be advised). Well spotted Jaakko and Paul. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: mike.nilsson(a)BT.COM <mike.nilsson(a)BT.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 31 August 1999 10:52 Subject: ASN.1 Syntax of H.245 >An error has been found in the ASN.1 syntax of H.245 version 5. Thanks to >Jaakko Helanti and Paul Long for identifying it. > >The error occurs in the section given below where the word 'OPTIONAL' should >appear at the end of the line 'genericModeParameters GenericCapability'. >This was an editorial error, but one that has some technical consequence. >Although the absence of the word 'OPTIONAL' does not change the >understanding of bits received by a decoder, it does demand that an encoder >always send the information 'genericModeParameters'. This was not the >intention and is not desirable. > >ModeElement ::= SEQUENCE >{ > type CHOICE > { > nonStandard NonStandardParameter, > videoMode VideoMode, > audioMode AudioMode, > dataMode DataMode, > encryptionMode EncryptionMode, > ..., > h235Mode H235Mode > }, > > h223ModeParameters H223ModeParameters OPTIONAL, > ..., > v76ModeParameters V76ModeParameters OPTIONAL, > h2250ModeParameters H2250ModeParameters OPTIONAL, > genericModeParameters GenericCapability > > >} > >I have contacted the ITU regarding this. Their response was that if there is >consensus, as determined by e-mail, then as version 5 (05/99) of H.245 has >not yet been published, it will be possible to correct this error before >publication. > >I hope that two weeks will be enough time for everyone to consider this >issue, and so aim to respond to the ITU on 13 September about whether we >have achieved consensus to make this correction. > >Best regards > >Mike Nilsson > > >********************************************************************** >* Mike Nilsson Tel: +44 1473 645413 * >* Applications Technology Group Fax: +44 1473 645011 * >* Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * >* BT Advanced Communications Technology Centre [B54 Room 94] * >* Adastral Park * >* Martlesham Heath * >* Ipswich IP5 3RE * >* UK * >********************************************************************** >

1 0

ASN.1 Syntax of H.245
by mike.nilsson＠BT.COM 31 Aug '99

31 Aug '99

An error has been found in the ASN.1 syntax of H.245 version 5. Thanks to Jaakko Helanti and Paul Long for identifying it. The error occurs in the section given below where the word 'OPTIONAL' should appear at the end of the line 'genericModeParameters GenericCapability'. This was an editorial error, but one that has some technical consequence. Although the absence of the word 'OPTIONAL' does not change the understanding of bits received by a decoder, it does demand that an encoder always send the information 'genericModeParameters'. This was not the intention and is not desirable. ModeElement ::= SEQUENCE { type CHOICE { nonStandard NonStandardParameter, videoMode VideoMode, audioMode AudioMode, dataMode DataMode, encryptionMode EncryptionMode, ..., h235Mode H235Mode }, h223ModeParameters H223ModeParameters OPTIONAL, ..., v76ModeParameters V76ModeParameters OPTIONAL, h2250ModeParameters H2250ModeParameters OPTIONAL, genericModeParameters GenericCapability } I have contacted the ITU regarding this. Their response was that if there is consensus, as determined by e-mail, then as version 5 (05/99) of H.245 has not yet been published, it will be possible to correct this error before publication. I hope that two weeks will be enough time for everyone to consider this issue, and so aim to respond to the ITU on 13 September about whether we have achieved consensus to make this correction. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * **********************************************************************

1 0

Release 2000 Architecture Adhoc meeting
by Edgar Martinez [1] 31 Aug '99

31 Aug '99

Dear All, I did not attend the 3GPP-2000 meeting. I passing this on for information only. If anyone has more insights on the meeting please provide. Regards, Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: Submission of draft-ietf-avt-rtp-text-00.txt to IETF
by H323MAIL 30 Aug '99

30 Aug '99

Hi Gunnar, I believe we had this discussion before - And I still find no justification to sending Text (which inherently must be lossless and is extreme low bit-rate) using RTP. Nothing stops us from opening an TCP channel using OLC/CLC procedures and sending text over it. I agree - when lip-sync is required, TCP delay (on average 1/3 for text chat type apps) may miss out a little, but I don't believe that to be such a big issue. The main problem I see is that using RTP on average text typist means that IP/UDP/RTP/Text packets are going to be sent every 2-3 characters, and even with redundancy, packetloss can still occur which is unacceptable. - gur The document "RTP Payload for Text Conversation" is submitted to IETF-draft as agreed in the avt wg in the IETF Oslo meeting. Comments are welcome to the author at gunnar.hellstrom(a)omnitor.se or to the rem-conf(a)es.net mail list. This RTP payload is used by H.323 Annex G Text conversation and text SET ABSTRACT This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. Gunnar Hellstr öm ______________________________________ Gunnar Hellström LM Ericsson Sweden Tel +46 708 204 288 or +46 556 002 03 Fax +46 8 556 002 06 Video +46 8 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom(a)omnitor.se WWW: http://www.omnitor.se

2 1

Re: RAS to INAP
by CHATRAS Bruno CNET/DAC/ISS 30 Aug '99

30 Aug '99

Dear All, The mapping proposed in this document (i.e. ARQ/ACF mapped to IDP/Connect) suggests that the RAS procedures are included in the BCSM. I do not think that this is valid, because the admission procedure occurs before call set-up initiation (i.e. it is too early for creating a BCSM instance). Indeed, in case the "direct" call model is used, no BCSM instance will be created after completion of the admission procedure. Moreover, it is almost impossible to find an obvious mapping between many of the ARQ/ACF parameters and the IDP/Connect parameters. Before trying to map the RAS messages on to INAP operations, we should first study how the RAS procedures can be modelled in terms of state machines. At a first glance, it seems that the RAS procedures might be considered as being some sort of non call related feature very much like a CCBS procedure. Therefore, it would be wise to study their mapping on to the BCUSM/CUSF model. If this model appears to be suitable, the ARQ/ACF message will naturally be mapped to the InitialAssociationDP and ContinueAssociation operations. However the mapping of parameters will still need to be considered. Alternatively, a deeper analysis may reveal that a completely new kind of state model (and associated set of operations) would better suit such kind of procedures. Regards, > ---------- > De : Edgar Martinez [1][SMTP:martinze@cig.mot.com] > Répondre à : Edgar Martinez [1] > Date : mardi 10 août 1999 16:26 > A : TSG11Q5 > Cc : TIPHON : Entirely; Entirely SG16 > Objet : RAS to INAP > > <<Fichier : 13td049.doc>> > Dear All, > > Attached is part of a document I presented in TIPHON 13 and > the Santiago ITU-SG16 meeting to support > INAP interworking in H.323. Which help to start the groups > (TIPHON and SG16), to look at INAP-IPT interworking. > The reason I sending this out I promise some reps. from > TSG11 to send the Mapping of the RAS to INAP messages > as a start. > > Regards, > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > >

1 0

Submission of draft-ietf-avt-rtp-text-00.txt to IETF
by Gunnar Hellstrom 28 Aug '99

28 Aug '99

The document "RTP Payload for Text Conversation" is submitted to IETF-draft as agreed in the avt wg in the IETF Oslo meeting. Comments are welcome to the author at gunnar.hellstrom(a)omnitor.se or to the rem-conf(a)es.net mail list. This RTP payload is used by H.323 Annex G Text conversation and text SET ABSTRACT This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. Gunnar Hellström ______________________________________ Gunnar Hellström LM Ericsson Sweden Tel +46 708 204 288 or +46 556 002 03 Fax +46 8 556 002 06 Video +46 8 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom(a)omnitor.se WWW: http://www.omnitor.se

1 0