- sg16-avd - lists.packetizer.com

Re: ASN.1 Syntax of H.245
by Hidenobu Harasaki 06 Sep '99

06 Sep '99

Dear Mike, > An error has been found in the ASN.1 syntax of H.245 version 5. I support the correction of the error on genericModeParameters. But another correction should be made. TTC (The Telecommunication Technology Committee), Japan has reported me that H.245 version 5 does not have section 6 but eighteen "defined in section 6" descriptions are found in Annex C. They should be corrected as "defined in Annex A". It might be a good chance to correct them before the publication of version 5. I also found that H.245 version 4 draft (included in h245_f.zip) has the same errors. :-< Best regards, Hideh Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Manager, Research C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

H.323 mobility aspects
by Edgar Martinez [1] 05 Sep '99

05 Sep '99

Dear Mr. OKUBO, Please (delete/remove) h323mob01.zip. and accept the updated contribution h323mob01a.zip for our next Study Group 16, Q.12-14/16 Rapporteur Meeting in New Jersey, 18-22 October 1999 I have put h323mob01a.zip , in http://standard.pictel.com/ftp/avc-site/Incoming/ The contribution deals with H.323 user and service mobility aspects. Thank you, -- 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/

2 1

RTP session related
by Sunil Chandra 05 Sep '99

05 Sep '99

Hi All, I have few doubts on the RTP session. 1. In any RTP direction of transmission, the destination TA that identifies the session, is also associated with a single RTP payload type. Let us say there is a MCU connected to three terminals a, b and c. a & b are transmitting G.711 A-law and c is transmitting G.729, then a & b can transmit to the same destination TA and for MCU be participant in the same session, whereas c has to transmit to a different TA and will be a participant in a separate session. Is it corret? 2. Can the session in the reverse direction have same session ID even if the payload type is different? If yes, why is this co-relation required? What is the criteria on which the master will decide the same session ID in both directions? 3. Is it required to have same session ID if the payload type is same in both directions? 4. Why the standard has fixed the session IDs for first session of each media type? Why these have to be same in each direction of transmission? 5. What happens to these sessions when a call is converted into an ad-hoc conference and GK becomes the active MC. The original sessions are closed but can the session Ids be reused this way? with regards, Sunil

1 0

Re: MC/MCU related
by Sunil Chandra 05 Sep '99

05 Sep '99

Hi Chris, >> 5. If a call signalling is routed through Gatekeeper, and there exists an >> MCU which is not involved in this call. Is it possible for the Gatekeeper >> to involve this MCU to create an ad-hoc conference from this call. If yes, >> what is the procedure? If not, why? > > You leave the biggest question until last... > And one close to my heart. > I've written a number of documents on this, and now I can't find any of them... > > The tricky bit is working out that this is what you want to do. > I assume you have a gatekeeper which routes both H.225.0 (extended Q.931) call > signalling and H.245 control signalling. > > First off, the gatekeeper uses terminal type for master-slave determination as > if it had the MCU functionality built-in. This is permitted because wherever > the standard talks about a gatekeeper having an MCU it uses the phrase "access > to an MCU". > When the gatekeeper decides a call needs to be split out into a conference (for > example, one of the parties in the call sends a setup using the same > conferenceID and different CallID & CRV) - or even on ARQ for this new call - > the gatekeeper does the following: > 1. Make two calls to the MCU, and get them to state "connected". > 2. Send the MCU the terminal capability sets for the endpoints in the existing > call (one on each call). > 3. Do master-slave determination on each call (the gatekeeper will be "master" > on the original calls, otherwise you're stuffed - but in this case there was > already an MCU in the call, so no problem) - in which the gatekeeper will end > up as "slave" (all MCUs beat all GKs). > 4. "Wire things up" internally such that instead of all the Q.931 and H.245 > messages going directly from one endpoint to the other, each endpoint talks to > the MCU on a different call. > ...and you have a two-party conference (as opposed to a call). The MCU will > now generate various exotic messages, and the endpoints will respond > beautifully - the gatekeeper just passes things through transparently now. Assume that the gatekeeper uses the half call model. Let us say that the callId of the original call was CIo, and callIds of the new calls from gatekeeper to the MCU are CIn1 and CIn2. Now, at the gatekeeper, there are two calls in the conference, one call has one call leg with callId CIo and other call leg with callId CIn1, and the other call has one call leg with callId CIo and the other call leg with callId CIn2. Now, if one of the terminals, want to send any call signalling message e.g. facility to its peer (terminal does not know it is connected to MCU), it will send this message with callId CIo. In this case, gatekeeper has to interpret the message and change its contents to reflect the new callId. This will make the gatekeeper very complex and lead to many interoperability issues as it will be very specific implementation of this feature as opposed to a well defined scenario in the protocol itself. > > Alternatives/extras: > If you trust people to have implemented H.450.2, or you care about everybody > paying properly for everything, > How are various charging models for supplementary services like H.450.2 and H.450.3. Are these very much same as SCN or some other models totally different from SCN models? How does charging issues affect the conversion of call into ad-hoc conference? > you could transfer the calls to the MCU using > H.450.2. > You could send some "CloseLogicalChannel"s to the endpoints in the original > call before connecting them up to the MCU, so that the MCU starts from a "clean > sheet". > > What I've given is a bit of an outline, and it does need a little refinement, > but essentially it should give you a call-to-conference transition with the > endpoints concerned having little or no knowledge of what's going on!!! > > Regards, > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001

1 0

Redundant silenceSuppression fields
by Paul Long 03 Sep '99

03 Sep '99

It doesn't really matter, but I was wondering, why are there two, apparently redundant silenceSuppression fields in the H.245 ASN.1 syntax, one in AudioCapability.g7231 and another in H2250LogicalChannelParameters? Paul Long Smith Micro Software, Inc.

1 0

None
by dhayanithi＠HSS.HNS.COM 03 Sep '99

03 Sep '99

=

1 0

"fastStart" in the Information message
by Paul E. Jones 02 Sep '99

02 Sep '99

Dear Experts, During the Santiago meeting, a request was made to include "fastStart" information in the Information message in H.225.0. That request was accepted and the field was approved as part of the Implementers Guide. Would the person (or people) advocating that change please contact me? Thanks, Paul

2 1

[Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]]
by Edgar Martinez [1] 02 Sep '99

02 Sep '99

Dear All, Very good questions: I passing this email on because MR. Binar questions highlights some key issues. Ed FAQ's on IP wireless mobility. -------- Original Message -------- Subject: Re: H.323 mobility first darft Date: Wed, 01 Sep 1999 17:15:17 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: "BINAR, Simon" <binar(a)isd-nec.co.uk> References: <199909011655.LAA02929(a)alba.cig.mot.com> Hi Simon, Thank you for your comments, Please read on... "BINAR, Simon" wrote: > Hi Ed, > > I looked at the document, and I would have a couple of > questions/comments about it. > > It seems to me that the draft provides the description of a complete > wireless access system. Yes, based on the SG16 Terms of reference. > However, I don't understand the point of > providing such a description, since wireless access systems suitable for > multimedia communications are being specified elsewhere (3GPP). Based on the Terms of reference and the Ad-hoc meetings we had in SG16. The assumptions where: 1. We will have H.323 wireless mobile handsets 2. We will provide IP mobility regardless of terminal type Fixed or Wireless 3. We will interwork with the legacy wireless (Networks and Terminals) which includes handovers.. 3GPP or 3GPP-2000 is based on GPRS and something called the layered approach to the IP network. Which ready means two separate networks one for IP and the other for mobility connected via a GW. The RAN interface (Iu-ps) to the GPRS network element is a lower layer ATM/AAL2 with IP on the upper layer connected to E-SGSN switch. I can not be convinced or believe that this is the pure IP solution for wireless. > > Shouldn't the wireless access system rather be completely transparent to > H.323 signalling? It is completely transparent, take alway the WAU and the HZR and you have your basic H.323 VoIP network. > > > Additionally, it seems to me that the proposed architecture does not > take into account mobility between fixed terminals. I can imagine > situations whereby a user could take his SIM card from one fixed H.323 > terminal to another. In such a case, mobility support at the H.323 > application layer would be required, however, no wireless access system > would be involved, and thus, components such as the WAU would not be > required either... Yes, you are right on the money, look at 8.2.1.5 "H.323 fixed terminal registration in a visited IP network" which implies exactly what you stated. The way it works from my research, is that the IMIS is programed in to the SIM card. The user ID is the IMIS once the user, that is, the IMIS is registered in the HZR. The user can plug the SIM card with the proper IMIS in a wireless terminal or fixed terminal. Please note that in the two fixed case call flows both 8.2.1.5 and 8.2.1.6 no WAU are used or shown. Only for the wireless cases. > > > ---------------------------------------------- > Simon Binar > NEC Europe Ltd. > Tel: +44 (0)1753 606933 > Fax: +44 (0)1753 606901 > EMail: binar(a)isd-nec.co.uk > ----------------------------------------------- > DISCLAIMER: Any views or opinions expressed in > this E-Mail message should be considered as the > personal views/opinions of the author. They do > not necessarily represent the views of the > author's employer. > > > -----Original Message----- > > From: Edgar Martinez [1] [mailto:martinze@CIG.MOT.COM] > > Sent: 23 August 1999 08:19 > > To: TIPHON(a)LIST.ETSI.FR > > Subject: H.323 mobility first darft > > > > > > Dear All > > > > I have uploaded the first H.323 draft, for user > > and service mobility. > > The focus of the document at the moment is to provide full > > mobility regards of terminal types, that is either fixed or wireless > > h.323 terminals. Only using H.323 messages with additional > > extensions to provide seamless wireless handover and > > terminal roaming. > > > > Anyone can pick-up a copy in following wed sites. > > > http://people.itu.int/~emartine/temp/ > or > ftp://standard.pictel.com/avc-site/Incoming/ > > The Filename is h323mob01.zip > > Comments are welcome. > > Best 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/ > > ------------------------------------------------------------------- > Mail archive for TIPHON can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- 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: MC/MCU related
by Lee Hyoung soo 01 Sep '99

01 Sep '99

Dear Sunil Chandra, For question 2,3, I don't have any idea. And for other questions, my opnion follows, Sunil Chandra wrote: > Hi Chris, > > I have following queries related to MC and MCU. > > 1. In H.323 section 6.2.8.4, there is a table which gives the terminal > types values for various terminal types. In this table there are certain > entries marked as NA. Does this mean that these terminal types are not > possible? for example, an MCU is not possible without an MC. I think some component which do not have MC is never be an MCU. > 4. Is it always necessary to have an MC in Gatekeeper? A Gatekeeper which do not have MC is not concerned with master-slave determination. So, in this table, a Gatekeeper which do not have MC was not considered. > 5. If a call signalling is routed through Gatekeeper, and there exists an > MCU which is not involved in this call. Is it possible for the Gatekeeper > to involve this MCU to create an ad-hoc conference from this call. If yes, > what is the procedure? If not, why? I think, H.323 terminal can involve other MCU's MC to make ad-hoc multipoint conference. And signalings between them is outside of standard. For example, someone can make MC as a stand-alone program like UNIX daemon, and use it for other terminal's ad-hoc conference expansion. Best wishes, soo.

1 0

MC/MCU related
by Sunil Chandra 01 Sep '99

01 Sep '99

Hi Chris, I have following queries related to MC and MCU. 1. In H.323 section 6.2.8.4, there is a table which gives the terminal types values for various terminal types. In this table there are certain entries marked as NA. Does this mean that these terminal types are not possible? for example, an MCU is not possible without an MC. 2. Why a terminal can not have a data MP? 3. Why there is no clause for an entity containing MC with audio MP only? 4. Is it always necessary to have an MC in Gatekeeper? 5. If a call signalling is routed through Gatekeeper, and there exists an MCU which is not involved in this call. Is it possible for the Gatekeeper to involve this MCU to create an ad-hoc conference from this call. If yes, what is the procedure? If not, why? WIth Regards, Sunil Chandra Hughes Software Systems

1 0

PEOPLE HELPING PEOPLE
by Warren 01 Sep '99

01 Sep '99

PEOPLE HELPING PEOPLE "GIVE AND YOU SHALL RECEIVE" READ THIS!!! THIS MAY BE THE MOST SIGNIFICANT LETTER YOU RECEIVE THIS YEAR!! Greetings, Hopefully my name is still on the list. When I first read the letter, I thought it was some off- the- wall idea to make money. A week later I met again with my client to discuss the issue. I told him that the letter originally brought to me was not 100% legal. I advised him to make a small change in the letter and it would be alright. I was curious about the letter, so he told me how it works. I thought it was a long shot, so I decided against participating. Before my client left I asked him to keep me updated as to his results. About two months later he called to tell me that he had received over $800,000 in cash!! I didn't believe him so he asked me to try the plan and see for myself. I thought about it for a few days and decided that there was not much to lose. I followed the instructions exactly and mailed out 200 letters. Sure enough the money started coming in!! It came slowly at first, but after three weeks I was getting more than I could open in a day. After about three months the money stopped coming. I kept a precise record of my earnings and at the end they totaled $868,439.00! I was earning a good living as a lawyer, but as anyone in the legal profession will tell you, there is a lot of stress that comes with the job. I told myself if things worked out I would retire from practice and play golf. I decided to try the letter again, but this time I sent out 500 letters. Well, three months after that I had a total of $2,344,178.00!! I just couldn't believe it. I met my old client for lunch to find out exactly how this program works. He told me that there were a few similar letters going around. What makes this one different is the fact that there are seven names on the letter, not five like most others. This fact, alone, resulted in more returns. The other factor was the advice I gave him in making the whole thing perfectly legal, since no one wants to risk doing anything illegal. I bet by now you are curious about what changes I told him to make. Well if you send a letter like this out, to be legal, you must sell something if you expect to receive payment. I told him that anyone sending money out must receive something in return. So when you send a dollar to each of the seven names on the list you must include a note saying "please put me on your mailing list" and include your name and mailing address. Follow these simple instructions exactly and within three months you will receive over $800,000.00. A) Mail a $1 bill (wrapped in a piece of blank paper) to each of the seven names below. Include a note (handwritten or typed) saying "Please add me to your mailing list" and include your name and mailing address.You Must include this note for this to be legal. 1. B & F Marketing 11 Circle Dr. Riverside, RI 02915 2. J. Russell 5201 Kingston Pk. #6-315 Knoxville, TN 37919 3. E-2000 Marketing PO Box 15185 East Providence, RI 02915 . Jerry Newland 220 Raven Dr. Clovis, New Mexico 88101 5. Kal Asi 16511 Whittier Blvd Whittier, CA 90603 6. J. R. Gann 3835 John Glenn Drive Granite City, IL 62040 7. Leonard McGhee PO Box 12727 Seattle, WA 98111-4727 B) Remove the name next to the #1 at the top of the list and move the rest of the names up one position. Then place your name in the #7 position. This is done by saving this to a file and then entering your information on line #7. Be very careful when you type the addresses and be sure to proof read them. C) When you have completed the above instructions you have the option of mailing your new letter in two ways. 1) Through US Postal Service or 2) through e-mail. This letter has been proven perfectly legal for both ways as long as you follow the above instructions, because you're purchasing membership in our exclusive mailing list. To mail this out over the internet, you could browse through areas and find people to send this to all the time. All you have to do is cut and paste e-mail addresses whenever you are on the internet. Or you can use a Bulk E-mail Network to mail your letter in large volumes for you. We highly recommend this method. Contact this Bulk E-mail company now. They have the lowest rates on the net and they are fast, provide effective results and give excellent service. They are running a special for $89.00 per 100,000 mailings and if you order now they are giving away an extra 50,000 mailings free. The number is 207-896-7915. Send this letter to thousands, even millions. This will bring big payoffs. ***Keep in mind that there is no limit to the amount of letters you can send out. The more you send, the more money you will make. We strongly encourage you to mail this letter to family and friends as well. THIS IS A SERVICE AND IS 100% LEGAL!!! (refer to title 18, section 1302 & 1342 of the U.S. Postal and Lottery Laws). This program is also, legal in Canada. Assume for example, that you get 7.5% return rate, which is very conservative. My first attempt was over 11%. 1) When you mail out 200 letters, 15 people will send you $1.00 2) Those 15 people mail out 200 letters and 225 people send you $1.00 3) Those 225 mail out 200 letters and 3,375 people send you $1.00 4) Those 3,375 people mail out 200 letters and 50,625 people send you $1.00 5) Those 50,625 people mail out 200 letters and 759,375 people send you$1.00 6) Those 759,375 people mail out 200 letters and 11,390,625 people send you $1.00 At this point your name drops of the list. Think about it. With only he first 6 levels, you have received over $813,615.00!! Amazing!!! THINK ABOUT IT Before you delete this program from your mailbox, as I almost did, take a moment to read it again and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when you participate. Figure out the worst possible response and no matter how you calculate it, you will still make alot of money! Any doubts you have will vanish when your first orders come in. IT WORKS! Now, smile all the way to the bank!! This is the power of PEOPLE HELPING PEOPLE. Stephen Corpas ///////////////////////////////////////////////////////////////////// // REMOVE AT mailto:kyydy@yahoo.com?subject=remove ///////////////////////////////////////////////////////////////////// //

1 0

Generate More Sales
by Pete 31 Aug '99

31 Aug '99

*** URGENT *** ACCEPT CREDIT CARDS FOR YOUR BUSINESS AND INCREASE YOUR PROFITS 30%-50% ! INTERNET STOREFRONT HOMEBASED OR MAIL ORDER BUSINESSES WE SPECIALIZE IN HELPING THE SMALL BUSINESS OWNER! IF YOU CALL IN THE NEXT FIVE DAYS YOU WILL RECEIVE: NO APPLICATION FEE NO PROGRAMMING FEE AND YOUR FIRST AND LAST MONTH LEASE PAYMENT IS FREE DON'T FORGET TO ASK ABOUT OUR WEB HOSTING AND DESIGN PACKAGE !!! CALL (888) 264-9272 OUR HOURS OF BUSINESS ARE 9AM - 6PM MST ///////////////////////////////////////////////////////////////////// / Please remove at mailto:kyydy@yahoo.com?subject=remove //////////////////////////////////////////////////////////////////////

1 0

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] 30 Aug '99

30 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

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

subscribe
by Yap Chee Ming 28 Aug '99

28 Aug '99

I would like to subscribe to the mailing list. Pls mail to qiming77(a)hotmail.com Thank you.

1 0

H.450.3 supplementary service
by vjaiswal＠HSS.HNS.COM 27 Aug '99

27 Aug '99

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

Mail List Commands
by Meyer, Greg W 26 Aug '99

26 Aug '99

Hi: I've seen several postings to this email reflector lately to either subscribe or unsubscribe. I want to make sure everyone understands how to interact with this mail list and its administrative program. This ITU-SG16 mail list is administered by the LISTSERV program. To subscribe, unsubscribe or get a list of past messages, you must send commands to LISTSERV, not the mail list. If you send commands to the ITU-SG16 mail list, those commands simply get broadcast to the list with no action taken by LISTSERV. Mail list administrative commands are sent to: listserv(a)mailbag.intel.com (mailto:listserv@mailbag.intel.com) The Subject line is ignored. The command is entered into the body of the message and has the syntax of: command ITU-SG16 parameters Some of commands with their <parameters> include: help ; to get command information to interact with LISTSERV info ; to get command information to interact with LISTSERV subscribe itu-sg16 <your full name> ; to subscribe to the list signoff itu-sg16 ; to unsubscribe to the list index itu-sg16 ; to get a list of digest files containing messages sent to the list get itu-sg16 <digest file> <file type> ; to get messages that have been sent to the list If your email address has changed (e.g. your domain name changed), you won't be able to "signoff" because you're sending the "signoff" using your new email address. Please contact me directly, stating your old email address and I will "delete" it from the list. You may then "subscribe" using your new email address. It's important not to reply to the mail list unless you're certain the response should be sent to the entire list. An example of a response that should *not* be sent to the entire list is an automated "Out of office reply". Some mail programs with automated responses are not well behaved and will respond every time with "respond to all". This can cause the list to enter an endless loop, fill everyone's mail boxes and crash the LISTSERV. If you cannot control your email's automated responses, please "signoff" from the list while you are away and "subscribe" when you return. You may contact me directly if you have questions or requests. Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506

1 0

Availability of H.323 standard
by Wolfgang Bandow 25 Aug '99

25 Aug '99

Hi all, can anyone tell me please, where to get the officially released version of H.323 and the corresponding referenced documents, as H.225 etc. In addition i would like to know where to get the H.450.1 ...9 standards from. Unfortunately i did not find any reference to the actual documents on the ITU-homepage. I'm looking forward to your answer. Regards, Wolfgang Bandow CT-B / Berlin

3 2