April 2002 - sg16-avd - lists.packetizer.com

FW: Question about the use of alternateEndpoints in ACF
by Lyons, Terry 05 May '02

05 May '02

> H.225 v4 contains this text: > "7.11.2 AdmissionConfirm (ACF) > ... alternateEndpoints - A sequence of prioritized endpoint alternatives > for destCallSignalAddress or destinationInfo." > > The feature seems intended to support robustness through redundancy in > large networks, > where there may be more than one media gateway capable of serving the same > AdmissionRequest (ARQ). > This would accord with the support for alternate gatekeepers in H.323 v4: > "7.2.6 Alternate gatekeeper procedures > For the purposes of ensuring system availability, redundancy, and > scalability, the Gatekeeper may provide the RAS signalling function by > utilizing multiple physical or logical devices, referred to as Alternate > Gatekeepers. If the endpoint supports the Alternate Gatekeeper procedures > defined in this section, it should include the supportsAltGK field in the > GRQ and RRQ messages. > When an endpoint initiates communication with the Gatekeeper, it may be > provided with a list of Alternate Gatekeepers via the GCF message. If the > Gatekeeper does not respond to the subsequent RRQ, the endpoint shall > attempt to register with the Gatekeeper using the list of Alternate > Gatekeepers provided in the GCF. If no Alternate Gatekeeper responds, the > endpoint shall reinitiate the Gatekeeper discovery process." > > The problem is that there are no procedures specified for the use of > alternateEndpoints. > What is it that causes a caller to terminate its Setup attempt to one > destination and to initiate a Setup attempt to the next destination in > priority order? > > Can we presume that the critical event is receiving a ReleaseComplete? > Then how do we determine whether the release reason or cause code is final > (no further Setup should be sent) or not (try another destination)? > Some calls should end after an announcement is played, eg. "The number you > are calling has been disconnected", > and will never succeed no matter how many alternative endpoints are > attempted. > > If the intention of alternateEndpoints has already been clarified > somewhere, please point me to it and excuse my ignorance. > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 >

3 2

"Early media" with fast connect
by Horvath Ernst 02 May '02

02 May '02

Dear experts, there seems to be a possible conflict with early media during call establishment using fast connect. Clause 8.1.7.1 of H.323 clearly says that the calling endpoint must be prepared to receive media right away on the ports it indicated in fastStart, and that the called endpoint may start transmitting media as soon as it accepts a fastStart proposal (unless, of course, the calling endpoint indicated also "mediaWaitForConnect"). This is independent of any Progress indicator. Clause 8.1.7.4, on the other hand, requires that the calling endpoint provides tones like ringback locally if it did not receive a Progress indicator #1 or #8. So the calling endpoint is obliged to interrupt/ignore possible media streams from the called endpoint and replace them with its own tones. Isn't this a conflict situation? I would like to hear your opinion or any experience from implementations. Kind Regards, Ernst Horvath Siemens AG

3 2

ITU-T SG16 Rapporteurs Meeting in June
by Paul E. Jones 27 Apr '02

27 Apr '02

Folks, As was previously mentioned, we are planning to hold the ITU-T SG16 meeting in Brugges, Belgium 24-28 June 2002. We are still working on the specifics of the meeting and I am not prepared to send a meeting announcement at this time with details, but what I would like to request is that you send me e-mail if you plan to attend the meeting. Please provide: Family Name, Given Name, Company, E-mail Address As a reminder-- as always, the Rapporteur's meetings are open to both ITU members and non-members. There will be a meeting fee for this meeting, which will be used to cover the costs of transportation to and from the meeting facilities, as well as to cover the cost of lunch and other meeting costs. At this time, I do not know what the amount of the meeting fee will be, but I expect it to be reasonable. I want to try to get a rough estimate of the number of people who will be attending the meeting, so I would definitely appreciate it if you can let me know if you will be attending. Best Regards, Paul

1 0

h235v2
by wu.yongming＠ZTE.COM.CN 25 Apr '02

25 Apr '02

hi,all experts is the following i marked by <<<>>> a error? i think it should possibly be H.245 control channe. 8.1 Secure H.245 channel operation Assuming that the connection procedures in the previous clause (Connection establishment procedures) indicate a secure mode of operation, the negotiated handshake and authentication shall occur for the <<<H.245 logical channel>>> before any other H.245 messages are exchanged. If negotiated, any exchange of certificates shall occur using any mechanism appropriate for the H-Series terminal(s). After completing the securing of the H.245 channel, the terminals use the H.245 protocol in the same manner that they would in an insecure mode. special to paul,because i am not sure this mail can get to the maillist,so i have send a copy to your address.if it is a trouble,please forgive me about that. regards, wu.y.m

1 0

H.460.1 editorial correction
by Paul E. Jones 25 Apr '02

25 Apr '02

Dear Experts, I received a consultation from the TSB regarding H.460.1, as to whether it would be proper to introduce a clarification for text in the third paragraph of Section 7.2. Specifically, the proposed change is from "If the feature is defined using ASN.1, then it is recommended that the PER encoding rules be used. ..." to "If the feature is defined using ASN.1, then it is recommended that the basic aligned variant of the PER encoding rules be used. ..." I personally support the correction since all H.323 equipment uses the basic aligned variant for PER encoding and using anything else would be incorrect. I would like to give the OK to the TSB for implementing this editorial correction, but would like to confirm with you whether there are any concerns with this change. We could of course incorporate it via an Implementers Guide later on, but we have the opportunity to have it right from the start. If you have concerns, please let me know ASAP but preferably not later than April 29, 2002. Best Regards, Paul

2 1

Re: Do we have any MMS Recommendations in the works
by Reddy, Paul K 19 Apr '02

19 Apr '02

Dear Campos-Neto, Q2/16, Q5/16 under WP2 have work items on Multimedia Instant Messaging and Presence Services. Very little progress has been made so far. Visit URL http://standar.pictel.com/ftp/avc-site for more information on the prevoius meeting documents. Regards, Paul Rapporteur of Q5/16 -----Original Message----- From: Campos, Simao [mailto:simao.campos@ITU.INT] Sent: Friday, April 19, 2002 8:37 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Do we have any MMS Recommendations in the works Dear colleagues, I would appreciate to hear from you if any MMS work is planned or being undertaken in WP2. Thanks, Simão Campos-Neto -----Original Message----- From: gregory.gamboa(a)toshiba-trel.com [mailto:gregory.gamboa@toshiba-trel.com] Sent: lundi, 15. avril 2002 18:01 To: pressinfo(a)itu.int Subject: [form2email] MMS This mail has been sent from the ITU web site to pressinfo(a)itu.int : SubjectMMS Bonjour, Do you have any recommandations/specifications on MULTIMEDIA MESSAGE SERVICE (MMS) FOR MOBILE PHONES. Merci, Greg.

1 0

Do we have any MMS Recommendations in the works
by Campos, Simao 19 Apr '02

19 Apr '02

Dear colleagues, I would appreciate to hear from you if any MMS work is planned or being undertaken in WP2. Thanks, Simão Campos-Neto -----Original Message----- From: gregory.gamboa(a)toshiba-trel.com [mailto:gregory.gamboa@toshiba-trel.com] Sent: lundi, 15. avril 2002 18:01 To: pressinfo(a)itu.int Subject: [form2email] MMS This mail has been sent from the ITU web site to pressinfo(a)itu.int : SubjectMMS Bonjour, Do you have any recommandations/specifications on MULTIMEDIA MESSAGE SERVICE (MMS) FOR MOBILE PHONES. Merci, Greg.

1 0

Application-Specific Megaco Error Codes
by Tom-PT Taylor 15 Apr '02

15 Apr '02

It has been bothering me for quite a while that we have no guidelines for the numbering of error codes, so they could be all over the map. For example, I created codes in the NAS packages starting with 100, simply because this was the first example of package-documented error codes. Since these codes were not yet registered with IANA, it may not be too late to enforce the following convention, following the precedent set by H.,248 Annex M.1: Proposal: application-specific error codes are assigned consecutive values starting at 600. Following on this proposal, I am changing the NAS error codes to 613-616 from 100-103. Comments? Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

3 2

Q.D,F,G,2-5 Rapporteur meeting
by OKUBO Sakae 11 Apr '02

11 Apr '02

Dear SG16 experts, After some discussions and negotiations, the next Rapporteur meeting date and place have been settled to 24th-28th June in Bruges, Belgium. Mr. Paul Jones will act as meeting organizer, and myself as document manager for this meeting. Paul will shortly post a preliminary announcement. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Re: Question
by Even, Roni 02 Apr '02

02 Apr '02

Gregory, The question is general. You need an MCU which is a multipoint control unit that serves as the conference bridge. You can have one MCU that everyone will use or two MCUs one in Brussels and the other in San Diego. The MCUs will be cascaded to have one conference. The cascading can be done using IP or ISDN. Regards Roni Even -----Original Message----- From: Gregory [mailto:gregoryduez@BELGACOM.NET] Sent: Friday, March 29, 2002 1:32 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Question Hi, I would like to implement a VC through the net between two companies one located in Brussels and the other in San Diego. What would be the best solution ? You have to take into account that 5 to 10 people would attend at each remote site ! Thanks for your help, Greg

1 0